In reference to:
An older system suffering from unintentional patching neglect was bitten by this bug.
I believe a few different symptoms can result.
My best assessment of things on this particular system include the following:
1) The database in question was a clone (via RMAN) from a production database that does not experience any symptoms. I have to attribute to possible SRID generating actions that may have occurred in the clone database after the cloning. One difference was that an unregistered ST_Geometry table in the clone was "registered with the geodatabase", but was not in production.
2) There is "essential" duplication of records in SDE.SPATIAL_REFERENCES AND SDE.ST_SPATIAL_REFERENCES, where in each table a pair of WGS 84 Lat/Lon records differ only by the SRID description field.
3) After manually correcting the SRID value in the SDE metadata tables to match the SRID on the layer's ST_Geometry features, then building a spatial index on the layer via ArcGIS, the SRID value in SDE.LAYERS would revert to the conflicting SRID. Was amazed to see this behavior--looked like an internal attempt to "fix" a perceived SRID / AUTH_SRID inconsistency.
4) A workaround (until a patch can be applied) was to drop the spatial index, correct the SRID metadata values, then manually create the index with SQL, and to avoid any spatial index operations with ArcGIS.
5) I also have a suspicion that while quasi-duplicate SRID records exist in SDE.SPATIAL_REFERENCES AND SDE.ST_SPATIAL_REFERENCES, there may be other possible impacts. A symptom we have on the "fixed" layer is that an ST_Geometry intersect operation between two layers is failing with an apparent SRID mismatch, but the layers are correctly configured. The shape column order in the intersect operation will work if the layer's SHAPE column is first, but not if it is second.
Obviously, more light can be shed on this, but I'm sure that things will be helped by de-duplicating SRID records and applying the neded patch.