Very preliminary searching seems to indicate that System.__ComObjects have a 'real type' one has to somehow get to, and that this has to be handled especially by applications lucky enough to recieve them.
Some more reading, and it appears that __ComObjects doesn't really have a "real" type, but rather implements a set of interfaces one has to query the old way.
Approximating this using Marshal:IsComObject and simply assuming the user knows what he is doing, I found that the excel example still wouldn't work because excel cheerfully also returns a non-COM object - an array - as a System.Object. The 'real' type of the object is available, and changing oldType to be container->getContainerObject()->GetType(); makes the excel example work again, but I wonder if it wouldn't be easier to just add something like UNSAFE-CAST or FORCE-CAST or something for working with Interop and similar situations. I'll fix it somehow anyway.
Accessing properties of COM-objects (without using the get_-methods) is also sketchy; but I don't think this could reasonably be called RDNZL's fault.
Regards, Iver