[Policy, no patch] Deprecating/Removing Core Modules

(This is a copy from the Slack thread here: https://drupal.slack.com/archives/C014CT1CN1M/p1656352055778989)
Unsure how to title this, went with [Policy, no patch], open for improving title changes.

This post tries to be in the spirit of what I said in a private DM to @xjm:

Basically I just want to get those damn modules out, you wanted those damn modules out, but in a user-friendly way. Turns out, your point of view is far superior than mine in this case.

After stepping back from the code issues around deprecation/deleting Core Modules for a bit, I think we need to make some decisions on policies around those first.
(Yes people, get your screenshot tools ready, I'm about to write some very "Un-Spokje" things...)

I think we (or at the very least I) were focussing on the very much needed code changes, but forgot about the even more very much needed user-experience during this whole process.

1. We decided that there's need for the Contrib Incarnation of the Core Module that is going to be deprecated/removed to exist, before the removal can be actually committed.
2. We can't currently do actual Drupal CI tests on those Contrib Modules in 9.5.x, since Contrib cannot test against that branch until there's an actual release out. That will be the case for every new branch. We can only remove in a new, not released branch and we can currently never test Contrib against a branch without a release. Possible solution: Ask the DA to make Contrib testing possible for at least the modules that we are deprecating in (for now) 9.5.x. (No clue if this is even possible or how hard this is to accomplish).
3. To make composer require drupal/contrib_incarnation_module possible and be able to test if composer require drupal/another_contrib_module_with_a_dependency_on_a_core_module_to_be_removed pulls in drupal/contrib_incarnation_module, I think we need #3292380: Remove the "replace" section from core/composer.json to land, DA to clear the calculated composer metadata cache manually and test the above.
4. If the above actually works, decide if we want to do this for the next release of 9.4.x as well. There are currently modules that are deprecated in 9.4.0, but the Contrib Incarnation cannot be composer required. (See for example https://www.drupal.org/project/color/issues/3292808 to see that people are already having problems with this.) If we decide not to do so, we need to communicate that quick and clear. Covered with #3292380: Remove the "replace" section from core/composer.json
5. When updating from 9.4.x/9.5.x to 10.0.x and having deprecated (and now removed modules) we do give a warning (See screenshot at the end of this message), however the linked page (https://www.drupal.org/docs/updating-drupal/troubleshooting-database-upd...) does not tell about composer require-ing the Contrib Incarnation. Also this warning is the "standard" one for missing modules. Do we need to make this more specific for removed Core modules? #3294914: Create dedicated error section for missing removed core modules/themes on update
6. Unrelated to the current process, but I would like to make the recommendation for new Core Modules that become stable, to, in a final step of that process, move all their integration tests to the module for which the integration is tested. Future me-s will thank you to not have to discover tests concerning a module to be deprecated/removed all over Core. Won't work: If module X tests integration with module Y, than it depends on which module is removed from Core (first). There's no predicting that.

Since I'm certainly not the Prince of Policy, I can imagine most of the brilliant improvements people will make on the above will need to end up in an issue, but for now I think it's OK to kick this of in Slack?

(This message has been approved by Sisyphus)