After mulling this over a bit longer, I recalled that the answer is in our default slapt-getrc, as shipped with final releases. I seem to recall my complaining somewhere about the effect when that answer is used by something different -- I don't remember what. But the method as-is does work. Here's how it goes. If I get something wrong, let me know; I'll edit this post.
- The packages repo is made up of only those packages which were included on the Standard release. It has no added priority, thus its priority is "normal", or "default".
- The extra repo contains packages that are not included with the ISO release, or that have been upgraded only because a newer version is available, and not because they're actually bugfixes or security patches. Extra's priority is the same as packages.
- The patches repo holds packages that were created to address specific problems like plain 'ol bugs or security fixes. The packages here almost always were present in other versions in packages or extra. In our default slapt-getrc, patches carries the OFFICIAL tag, which gives it a higher priority than the other two stable repos, or untested.
- The untested repo isn't active in the slapt-getrc as shipped with FINAL releases. It's the only repo available to releases still in development. That difference is where my confusion started, I think. Untested has normal priority like packages or extra but, again, it's off by default for stable releases.
There's an implicit rule to be remembered here. The list of packages already installed on the system is treated as if it were a repo with
normal priority. That is to say that the highest-numbered version present in a higher-priority repo,
patches in our case, is what is chosen as what should be on the system. Between packages, extra, and the target system, highest-numbered version is what ends up as installed, period. For the higher-priority patches repo, you're going to end up having whatever
its highest-numbered version is,
regardless of the version already installed on the system. That's something to keep in mind when upgrading software locally. While this seems like a mistake, it does give us the option of using a lower-versioned software as a patch. With the development practices of projects degrading generally, this is happening more and more now.
The answer to my initial question, then, is this:
A packager should base a bugfixing package on whichever version of the software is proper, regardless of the version number already in use. For any package, mention in the commiit message whether this is a package that's new to us, a feature/version upgrade, or a bugfix or patch. Include that same info when it's time to request the package be moved from untested to stable repos. New packages or feature upgrades will be placed in extra (packages is fixed at release time), and fixes will go in patches. If a higher-versioned package is already in patches, the repo maintainer will remove that manually so that your patch will take effect.
It took some unthinking to sort this out, and I had to resort to a live test. Easy when you know it, not so easy if you're me and you don't.