Thanks for the report @snowman2! Looks like it's from #3080 as well. This keeps on giving.

Ah, there's a reason I have deja vu, closely related to or the same as #2966 (comment) I think, and the fix in pandas 2.3 is pandas-dev/pandas#56761 - I guessed we missed this as an implication of backporting this to silence errors.

The return GeoDataFrame._from_mgr(mgr, axes) line in _constructor_from_mgr doesn't preserve metadata natively, so we're reliant on a follow up call to __finalize__ (and previously, this wasn't an issue because the geometry column was called geometry, and _geodataframe_constructor_with_fallback caught that case.

Perhaps we should have

    def _constructor_from_mgr(self, mgr, axes):
        # replicate _geodataframe_constructor_with_fallback behaviour
        return _geodataframe_constructor_with_fallback(
                pd.DataFrame._from_mgr(mgr, axes)
            )

and try and improve the sindex caching directly.

Perhaps we should have

Other alternative could be to mimic what the constructor was doing in the else block that currently just does return GeoDataFrame._from_mgr(mgr, axes).

So before, this mgr was passed to GeoDataFrame(..) instead. And my understanding is that then:

• the mgr was passed to super().__init__(), thus setting up the DataFrame (that is now handled by our inherited _from_mgr, I think)
• if there was a column named "geometry", we would try to ensure this was a geometry dtype column, and when this succeeds, set the geometry name to "geometry"

That's it, I think. So IIUC, we just set the active geometry column name to "geometry" if that column name was present and contained geometries.

That's something we could also mimic here to avoid the overhead of the full constructor?

That's it, I think. So IIUC, we just set the active geometry column name to "geometry" if that column name was present and contained geometries.

I think that's right.