Also cherry-picks to stable branches should never be nice-to-have. We should only cherry-pick bugfixes into stable branches, by definition.

Ah, yes. I was intending to mean: nice to have for .1 specifically. They still may make sense for .2. For instance, if there was a bug that meant 2.19.1rc1 was non-functional (e.g. problem in something that was cherry-picked already), we should do a fix for that before doing 2.19.1, but if something is "just" a general fix, maybe we should wait a bit and let it fall into .2, or else the branch will never be stable enough to do .1.

Also cherry-picks to stable branches should never be nice-to-have. We should only cherry-pick bugfixes into stable branches, by definition.

The release strategy in the docs say we may pick features as well…. I’d add to that it would depend on the state of the current version when that may be done (i..e not during a rc phase)

Hmm I think that sentence in the release strategy is in error then. If we cherry-pick features to a stable branch then what is the difference between that stable branch and the current latest release branch?

a subset of new features.. also new features that are picked from an already released stable branch, so should be vetted already. (the last part may not be part of the docs, but I think it could make sense to not pick new features until they've been properly released first..)