indeed it is time to adapt that - but the adaptation - for now - will be minimal.
In the most recent discussion we have considered that the main content will always be meant to apply to the latest version. Older versions are still meant to be covered and where differing they should be marked accordingly.
The reality is that maintaining them separately just is an entry to redundancy and all the issues that come with it. And on the other hand the majority of entries does not change often. For those that do it would be something like “Note: in releases before XX.YY …”.
Former: “To achieve foo, do bar”
New: “To achieve foo, do foobar … Note: in releases before XX.YY …”
That allows to document for example a feature that is added in between LTSes already when it is added. We’d just state that it was not available before XX.YY. And it allows - if it changed how to do things - to outline both versions. The scale of this depends on a case by case decision. For example if on a page 95% stays the same but one aspect is different, then a little Note before a section will do. If on the other hand e.g. handling a particular workload was totally changed (e.g. we changed which program is in main to handle it) then that would more likely be an intro page linking to older/newer content.
If down the road we really have a proliferation of content due to “too many versions” we can think about splitting it, but right now that should result in the best outcome for a rather low effort.
The page already says “Ubuntu 20.04 LTS (Focal Fossa) and later” to reflect that. I’ve found that we also need to change the PDF link to say the same and I should mark the “and later” just as bold as the rest.