Everything that the CLC has in the works that affects the Prelude already has been brought up most of the way to this standard, in that
gives the summary of the resulting timeline with the outstanding proposals worked out in in a user facing manner.
It doesn't enumerate the explicit actions the user should take at each step to build in whatever the 3 release compatible mode would be at any given point, however. Help on that front would be welcome.
A few details change if the Simons choose to ultimately roll -Wcompat into -Wall, as the 3 Release Policy takes a bit of a hit, but the general timeline remains intact.
My primary concern is that if we ask end users who put forth proposals for excruciating detail that considers everything in the 3 release policy, we limit ourselves to proposals that come from people already deeply familiar with the process.
The current mindset is that if we do choose to adopt a proposal once the community has agreed to the broad strokes, we'll need to do what we can to raise it to this level and incorporate it into the roadmap.
Currently we're doing so with respect to Prelude-affecting changes, but spreading this (or something weaker) out to the wider set of core libraries is something we could consider doing once we get a sense of how well it is working in practice, and if there is a general sense that the stability it brings outweighs the rather significant delays it imparts to the process.
Keep in mind we already have plans that stretch out to GHC 8.6 as a consequence of the 3 Release Policy. Almost all significant changes will now take around 4 years to play out. Around the Prelude that seems about right. Around the rest of the core libraries that would likely become a rather significant pain point.