Although rare (and not recommended!), it can happen that a same exact
RNA path points to a different type of data.
This can come from an update of the code itself, but this is very
unlikely and discouraged.
However, geometry nodes and their 'modifiers' interface have made it way
more easy to create such conflicting situation, since users are free to
re-arrange and edit the nodes and their 'public' interface as they
want...
Found out while investigating some unrelated issues in some studio Gold
production files (namely,
`pro/shots/090_joining_whale/090_0130/090_0130-anim.blend` r2110
exhibits such issue for `OBGEO-mika-body`
`modifiers["RIG-GN-mask-clothing"]["Socket_3"]`, where the RNA type
changes from integer to bool).
NOTE: Cherry-pick of 6adf5adb7f, had to do some non-trivial changes to
get it to work in older code though.
Second issue reported in the comment was caused by some shapekeys
flagged as embedded liboverride data, when their owner ID (Mesh e.g.)
is not a liboverride at all.
The `BKE_lib_override_library_validate` called on file read was only
covering real liboverride IDs, which where then supposed to take care of
their own embedded data. But since the owner ID is already a full
non-override ID, its embedded data ended up never being properly
sanitized.
Most likely more corruption data from quite old files and/or deprecated
experimental features.
`BKE_lib_override_library_validate` used on fileread to ensure all
liboverrides are valid was using direct call to
`BKE_lib_override_library_free`. However, this was lacking the handling
of embedded dependencies (from liboverride PoV), in particular
ShapeKeys.
Since these shapekeys were still tagged as embedded liboverrides,
liboverride code would later assume their owner (mesh etc.) was also a
valid liboverride, leading to various potential issues.
Use instead `BKE_lib_override_library_make_local`, which also ensures
that embedded dependencies are handled properly.
Bastien Montagne