Moving this conversation here as this thread is about SRU policy vs. the other one that is only about a specific update.
Assuming that you mean adding a Breaks: package relationship in a gnome-shell microrelease SRU, such that extensions installed from the archive will need to be removed before gnome-shell can be upgraded, I’m not sure that’s safe. If there’s a subsequent security update to gnome-shell, what’s that going to mean for users who are using such shell extensions from the archive? Will apt refuse to install the security update, or will apt force the removal of the extension packages? Either way seems unacceptable to me.
I think an essential requirement for an SRU is that nothing in the archive is knowingly broken as a result of it. We released with these extension packages, and our stability promise we make is that we won’t break them. It then follows that declaring “extensions we can’t support” cannot be used as an excuse to break this promise. However this is probably outside of the scope of the SRU team to decide; I think that if we want to deliberately break compatibility with other packages in the archive in an SRU, then that’s outside the scope of the microrelease update permission given to the SRU team by the Technical Board and so such an exception proposal would have to go back to the Technical Board for their consideration.
An alternative might be not to release such extension packages at all if they’re going to block gnome-shell microrelease updates like this because nobody is committing to do the necessary work. I am generally in favour of removing packages that aren’t being looked after and are also blocking progress. Again that’s not up to the SRU team though; that’d be something to clear with the release team.
Note however that in the case of this particular regression we found that people are using the package and @fcole90 did step up to do the necessary work. Whatever we do, I think we need to figure out how to fit those extension packages into the gnome-shell SRU process so that those who are willing to look after these packages like this can continue to do so without users being regressed first.