I disagree. My first response to an EOL question will always be to vote-close as off-topic it for being EOL, or as a dupe to the old-releases question, *unless someone conclusively proves that*:

- The question is independent of release
- NO answer is specific to that release
- Upgrading to a supported release will not solve the issue

In particular, consider [Eliah Kagan's comment][1] in your first example:

> ... this is in the minority of new questions about a problem in an EoL release where (a) we know the answer is release-independent, and (b) both the question and the answer (because they involve a common activity with a non-obvious pitfall) seem like they may be of especially high value to others. This could be edited to generalize it to all releases ...

For example, say the poster has a problem with $EOL_RELEASE. Let them post it. If they, or someone else, shows that it also happens on $SUPPORTED_RELEASE, we can simply reword the question to make it on-topic. If they can't, close vote or perhaps migrate to U&L.


And your second example is a non-problem, so it's already covered by the current wording. It's more curiosity than anything else. If someone asked a question about the reasons behind the migration to `systemd`, I wouldn't close it, since it is *not a problem*. (It might be too broad, though.) No change needed here.

My main issue with this proposal is this:

###The proposed wording shifts the burden of proof from the poster to the reviewer, whereas I want it to be solidly on the poster.

The current wording is fine by me.

If the poster really wants help, let them post on [Unix & Linux][2], where we have no restriction on releases, and where quite a few of us are also active. We have a set of topics on-topic here, and EOL/development release problems are not in that set.


  [1]: http://askubuntu.com/questions/534044/error-32-bit-linux-android-emulator-binaries-are-deprecated-when-attemping-to-r/#comment730478_534044
  [2]: http://unix.stackexchange.com