So I guess this is at least partially broken again:
http://tickets.musicbrainz.org/browse/MBS-7053

Unlike above examples, there are no fingerprints.

@HumHumXX: That recording has PUIDs, so it won't be deleted.

Different example: http://musicbrainz.org/recording/b9ab95d0-1237-4787-8f9c-cca64aba389e

No "Add track" or "Add standalone recording" edit. The track on that Ministry of Sound release was (erroneously, I think) linked to http://musicbrainz.org/recording/780e9c96-97cf-4c32-a280-a11eb43382b8 in http://musicbrainz.org/edit/14479729. (Btw, shouldn't this edit be listed in the recording history?)

Looking at the edits in the database and comparing them with an edit I know was for a non-album track, there isn't enough information there to know whether or not those tracks were originally non-album tracks or not, so I don't think we can do anything about those.

Two examples of orphaned recordings ("tracks", back in the day) that were added not as standalone recordings but to releases that have been removed in the meantime:

http://musicbrainz.org/recording/3540562f-ce15-476c-b8c4-331a51d30a4b/edits
http://musicbrainz.org/recording/6df4632b-070b-4f6f-9e8a-227a01faadd3/edits

Thanks! Is MBS-5126 affected as well?

The cleanup script has run (and deleted 19379 recordings), and the triggers to automatically do this have been added. As far as I'm aware, this fixes the issue. If you still find recordings that you don't think should exist, please reopen this ticket.

Assigning to me, I'll begin looking at this tomorrow morning.

Let me reiterate that this bug, combined with MBS-5126, is severely affecting the quality of the data that we provide to our customers (if we want to put it that way).

Upping this to major because this bug necessitates lots of recordings cleanup not only after remove release edits, but also (almost every time) when a release add was canceled or voted down.