the session manager is responsible for this, though the way it's defined in the XSMP specification makes it almost impossible to get right (one of many ways in which XSMP is totally broken)

there could be a metacity bug but it's probably just a general session management thing.

How about, when Metacity starts up, it deletes all session files except the oldest (say) four?

I agree about the brokenness of XSMP, but everyone will hate us if we turn it off :/

I wasn't saying to turn it off, the point is that gnome-session is supposed to be running the command to delete the files, in theory. gnome-session is probably broken. Not sure it's possible to implement this part of xsmp correctly.

Deleting old files would surely be fine in practice, though in theory it's wrong.

I noticed that almost saved files are empty. 98% of them contain only:

<metacity_session id="11xxxxxxxxx">
</metacity_session>

Could this be avoided?

Since March  2007 till now I found nearly 1500 of these files in my .metacity/sessions and session autosave is not even enabled. 

Can gnome-session remove them on startup or never write them down if autosave is not enabled? As in comment #4 almost all of the files are empty.

Bump. Confirmed on gentoo with metacity-2.24.0-r2 and gnome-session-2.22.3-r1.
Is there any progress with newer versions ?

bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be fixed.