CONNECT BUG: sys.dm_tran_active_transactions inconsistently reports the state of transactions

I filed this bug as well today regarding implicit transaction handling.  

There are actually a few possible bugs here (or inconsistencies in BOL for sys.dm_tran_active_transactions). After running the repro script (attached) it appears as though the rule for this DMV is that sys.dm_tran_active_transactions returns the "name" of the OUTER transaction (or implicit_transaction) and never any rows for the inner transactions as long as transaction_status2 = 258 (which I'm guessing means non-marked transactions). When a transaction is marked then sys.dm_tran_active_transactions returns the outer most named and marked transaction regardless of whether there is an implicit_transaction. We can deduce this because transaction_status2=266, which, I guess, means HasMarkedTransaction. I understand that transation_status2 is "not supported and future compatibility is not guaranteed." 

This is not just esoteric innards of SQL Server that can be easily dismissed. jdbc drivers follow the dblib pattern for implicit_transactions whereas ODBC/OLEDB does not. The latter also issues (when configured) "sp_reset_connection" that handles weirdness such as "dangling transactions" that sometimes occur due to deadlocking at the business tier. jdbc/dblib doesn't have the luxury of calling sp_reset_connection. Our application is having issues where some pooled connections have their implicit_transactions set incorrectly. It's been impossible to figure out where though. We would like to be able to monitor this with the DMV, but cannot since it handles these situations inconsistently.

Here is the attachment.