I believe we're implementing a plan in which raws are protected from expiration in OODS by adding them to TAGGED collections, but this may be based on a faulty recollection of how this would work.

At a low level, the database rows that store dataset membership in TAGGED collections have a foreign key to the dataset table marked with ON DELETE CASCADE, which means, "if the dataset is deleted just delete this membership row, too" - so there is no foreign key protection against TAGGED dataset deletion.

There may well be higher-level guards; some of our deletion APIs do a lot of querying in advance to figure out whether it's safe to delete something, and these may perform such a check. But if we want a rigorous guard against TAGGED dataset deletion, we should change this foreign key definition. I think we do want it: even aside from the OODS use case, this has long been an uncomfortable asymmetry with how CHAINED collection membership works, where the philosophy is that you shouldn't be able to blindly delete something you own without at least being told when someone else might be depending on it.

I'm not sure this ticket will be easy-ish (it may just be a two-line code change, but is definitely also a minor schema migration, and that's always a pain) or much harder; the hard case would enter because the TAGGED member table is also the RUN membership table, and we may be relying on ON DELETE CASCADE to remove datasets from RUN collections, and if we are, I don't know how hard it would be to change that.