Thanks for opening this discussion,

I will share some insights from my work with software written by and for scientists (biologists, physicists) and the way these people use the software.

1. What is the specific motivation for trying to use a non-last version in a version line, especially an EOL one?

My reason

• In my case I am working on updating a client's custom softwares written in python - they happened to were developed using python 3.6.8, so I started from there to make it first work the way it was provided.

Other Reasons why people might use the non-last version in a version line:

1. Non-specialists do commonly not know about the implications of the patch release numbers. They use the software as a tool to make their calculations and if it works, it works. (example: bioinformatics or biology applications)
2. Because they already have a non latest release running and they 'just want to make it work'.
3. Because they need to "make work" a software that is written for python 3.6 and THEREFORE they go on to install python 3.6.

• They will google search "install python 3.6 linux" and then one of the first results that pops up is python 3.6.8. Take it. +
• The python 3.6.8 page says

Note: The release you are looking at is Python 3.6.8, the final bugfix release for the legacy 3.6 series [...]. The final source-only security fix release for 3.6 was [3.6.15] [...].

-> they will stick with 3.6.8 that seems to be the "final release available ready-to-go".

• If they are the average scientist, then they will prefer downloading a ready-to-go package and NOT compile from source (because actually they want to spend their time on their biology calculations and not on making some python run!)

Fix Possibilities?

• Provide compiled versions for the last patched version with the backported downstream patches e.g. compiled python 3.6.15 with backported downstream patches
• and add a very visible banner to all pages of 3.6.x that redirects people's attention to the one and only to go python 3.6.15

2. Should we backport downstream patches for the aforementioned versions, or some of them?

Yes, since many softwares written for biology computations is python 2 or python < 3.7. Unfortunately I cannot provide statistics here, this is only my experience with those softwares.
I cannot estimate the effort involved, maybe you have some usage or download statistics for the different versions. Then choose the most downloaded one?

What is the specific motivation for trying to use a non-last version in a version line, especially an EOL one?

The reason I was doing this is because the project I was working on used a very specific Python version and I wanted to match that version exactly for local development. It may not make a huge difference, but is always best to make local environments match the deployment.

For EOL versions, this has to do with supporting older versions of an application running with an older Python version. While it may be EOL from the upstream point of view, that version may be under extended support by another vendor. I frequently need to reproduce bugs using specific older Python versions. Definitely a very niche use case.

I'm working relatively low-level with python bytecode and .pyc files of various versions, which is why i need many different python versions in the first place.
Since bytecode changes can happen between all kinds of version changes, i need to use python versions that have a matching bytecode version to the .pyc file i'm working with.