Bug with Base LVOOP object variants and flatten string.

Question

I found a bug when if the base LabVIEW Object is wrapped in a variant (even indirectly), it cannot sucessfully be flattened to and from a string.
Neither of these should produce an error.
And if you try to work around it with XML, it can lockup or crash.

Answer 1

The first is the simplest demonstration of the problem.
The second is to show that problem is indirect (through multiply layers of different structures).
As for the purpose I was writing a SQLite interface that could write any form of LabVIEW data while maintaining variant attributes. I have to serialize the data somehow so the first attempt I just packed it into a variant then turned that into a string with flatten to string (since the variant contains the type info for what it holds I just need to use the type info for a variant to unserialize it). That failed with the first bug if I tried to store a variant with a attribute holding something down classed to the LabVIEW base object.
So instead of wrapping it in a variant I tried directly flattening it to a string and storing the type info from variant to flatten as a pascal string at the front of serialized data (of course this breaks if a LabVIEW object two variant levels deep is passed in). But that destroys variant attributes. So I tried wrapping that in a cluster then flattening the cluster (hence error two, and since it's indirect I can't wrap it in anything to avoid the problem).
So the current work around is to never store anything in the LabVIEW base object. So If I wanted a generic LVOOP container I would have to make a class for storable items then everything that can be stored would have to inherit from that.
I'm mainly posting since unknown bugs are rarely fixed, and this one is a bit obscure.