What you have found here appears to be a bug in the data dictionary and was reported as Bug 34293726 - Wrong object_id in ALL_OJBECTS leading to wrong results.
Please don't get misled by the title of the bug itself, it is still to be determined whether or not the object_id in all_objects is wrong or in the other views.
The object_id reported in all_objects within the PDB is from a sub-object that is inherited by the CDB, while the other views report the object_id from the CDB itself.
In my database, the DBMS_STATS package has the object_id of 16334 in the CDB itself:
SQL> select object_id
from all_objects
where object_name = 'DBMS_STATS'
and owner = 'SYS';
OBJECT_ID
----------
16334
22401
SQL> select distinct object_id
from all_procedures
where object_name = 'DBMS_STATS'
and owner = 'SYS';
OBJECT_ID
----------
16334
SQL> select distinct object_id
from all_arguments
where package_name = 'DBMS_STATS'
and owner = 'SYS'; 2 3 4
OBJECT_ID
----------
16334
In the PDB, however, the object_id in all_objects is 16335:
SQL> alter session set container=cdb1_pdb1;
Session altered.
SQL> select object_id
from all_objects
where object_name = 'DBMS_STATS'
and owner = 'SYS';
OBJECT_ID
----------
16335
22398
SQL> select distinct object_id
from all_procedures
where object_name = 'DBMS_STATS'
and owner = 'SYS';
OBJECT_ID
----------
16334
SQL> select distinct object_id
from all_arguments
where package_name = 'DBMS_STATS'
and owner = 'SYS';
OBJECT_ID
----------
16334
What's happening here becomes clearer when looking at cdb_objects in the CDB (which reports all objects within a CDB, or all objects within the PDB alone when executed in the PDB itself).
SQL> select con_id, owner, object_id, object_name, object_type
from cdb_objects
where object_name = 'DBMS_STATS';
CON_ID OWNER OBJECT_ID OBJECT_NAME OBJECT_TYPE
------ ------ --------- ------------ ---------------
1 SYS 16334 DBMS_STATS PACKAGE
1 SYS 22401 DBMS_STATS PACKAGE BODY
1 PUBLIC 16335 DBMS_STATS SYNONYM
3 SYS 16335 DBMS_STATS PACKAGE
3 SYS 22398 DBMS_STATS PACKAGE BODY
3 PUBLIC 16336 DBMS_STATS SYNONYM
Note how object_id 16335 in the PDB (con_id = 3) shows up as the package itself, while in the CDB (con_id = 1) the same object_id is reported as the public synonym. Meanwhile, the object_id 16334 refers to the actual object present in the CDB which is shared across PDBs.
The missing linkage is with the other ALL_* views inside the PDB, which are referring to the object in the CDB with object_id 16334 that happens to be an entirely different object in all_objects in the PDB:
SQL> select con_id,owner, object_id, object_name, object_type
from cdb_objects
where object_id = 16334;
CON_ID OWNER OBJECT_ID OBJECT_NAME OBJECT_TYPE
------ ------ --------- ------------------ -----------
3 PUBLIC 16334 XS$ROLE_GRANT_LIST SYNONYM
Is this a known bug in the dictionary views? Or am I misunderstanding the semantics of the OBJECT_ID, which I believed was a unique object identifier across the dictionary?
You do understand the semantics of object_id correctly, this appears to be a bug and has been reported.
It may be also worthwhile to point out to other readers of this thread that one thing that has changed with the introduction of the CDB architecture is that there are multiple hierarchical dictionaries in play now. There can be up to three dictionaries: CDB --> (Application Root) --> PDB.
The Application Root container is not mandatory, in the case above the hierarchy was simply CDB --> PDB.
In either case, the child inherits the objects present in the parent, i.e. objects in the CDB are available to all Application Root containers and objects available to the Application Root container (which includes objects from the CDB) are available to the PDB.
And this is exactly what you see above in the inconsistency. Object 16334 is the object in the CDB, the actual DBMS_STATS package and object 16335 is the inherited package linkage in the PDB back to the CDB.
