Wouldn't polymorphism be moreso like:
Your example describes Function Overloading, which is a type of ad-hoc polymorphism. This is not the only kind of polymorphism. Please read the Wikipedia page on polymorphism.
Excerpt: Using parametric polymorphism, a function or datatype can be written generically so that it can deal equally well with objects of various types. For example, a function "append" that joins two lists can be constructed so that it does not depend on one particular type of list: it can append lists of integers, lists of real numbers, lists of strings, and so on.
Although my system looks more complicated, I would suspect that Handle/Object are performing similar functions behind the scenes.
Frank, you're comparing apples and orange-coloured fertilizing equipment here. Your system is a stack-managed vector container, while your "handle/object version" isn't even a container. Simply calling Handle() on something doesn't add it to a container.
Take a look at my linked list library and you'll see that it's managing the Handles in a perfectly normal linked list. I could easily write a stack-managed vector identical to your object management system (yes, with separate, assignable IDs!) which would manage Handles instead of objects - the difference would be that I wouldn't need to copy code every time I wanted a new container, and I could pass my containers to functions, and even store them in other objects. I'd also have a miniscule performance reduction for Blitz's Object/Handle overhead.
The container type you're advertising is great and everything, and I'm glad it's served you so well, but it's not ideal for all purposes; if it were, the other container classes wouldn't exist. IDs are great too, but linked lists don't use IDs. If Shifty Geezer says he wants a linked list, assume that he does.