As far as I understand with "read uncommitted" policy we can see two versions of the same tuple if it was updated by two transactions both of which were started before us and committed during table traversal by transaction with "read uncommitted" policy. Certainly "read uncommitted" means that we are ready to get inconsistent results, but is it really acceptable to multiple versions of the same tuple?
"In general, read uncommitted will return inconsistent results and wrong answers. If you look at the changes made by a transaction while it continues to make changes then you may get partial results from queries, or you may miss index entries that haven't yet been written. However, if you are reading transactions that are paused
at the end of their execution for whatever reason then you can see a consistent result."
I think I already covered your concerns in my suggested docs for this feature.