If the data_object_id is not unique within a database as Tanel Poder demonstrated (albeit from 2008), then how does Oracle uniquely determine the tablespace from the ROWID in order to make use of the ROWID's relative_fno?
For example, a global index on a partitioned table whose partitions are in different tablespaces would require the extended ROWID in the global index to uniquely identify the tablespace of the row to which the index entry refers.
I am using Oracle Enterprise Edition 19c, but I suspect the answer only requires Oracle 8+.
Poder's article demonstrates ROWID duplication within a database, but not within a table. When using a ROWID, whether from an index or explicitly in a WHERE clause, Oracle knows what table its coming from. That narrows down the possible reference of the data_object_id to only one possible partition/segment, which means only one possible tablespace.
The example Poder gives of a potential problem is the unrealistic scenario of a program using ROWID as a kind of global identifier across tables with a uniqueness relied on by user code, which nobody should be doing. (Not only is it nonsensical to attempt a global identifier across entities, but ROWID should never be used by code outside of the lifetime of the cursor that fetched it, let alone as a permanent identifier. It's volatile, and will change if the row moves due to update of a partition key column or partitions are split, merged or exchanged, or if a DBA or scheduled management script does any move/reorg/compression work.) So it's a "problem" that probably nobody, or nearly nobody, will have run into since this was introduced in Oracle 8.