We try to manage these things at the repo level - changes like licenses are done in the trunk of each package checkout, and may not be merged into the actual real PKGBUILD until the next time it is changed.

Yeah, that's right; anyway let me try to explain a little better when this is useful:
aalib-1.0-1 has a minor error, like the wrong $url, so the maintainer fix it and release aalib-1.0-2 WITH the stick option; if user1 already have aalib-1.0-1 installed on his machine, then pacman won't update to aalib-1.0-2 (unless user1 explicitly tells pacman to do it), but when user2, who doesn't have aalib-1.0-1 installed, tells pacman to install aalib, pacman installs aalib-1.0-2. This way user1 didn't have to download the whole new aalib for a minor change, but user2 has the fixed package.

Doing what you usually do now, user2 would have still aalib-1.0-1 installed. Not a huge problem, I agree, but maybe someone think this feature is cool and want to implement it.

In b4, patches welcome :)

If I understood correctly Aaron's standpoint, AL doesn't release new version in order to fix such a small thing, they fix minor issues in the next 'real' release instead. Right?

That's correct. Not saying this is a bad idea, I just don't think we'd get a lot of use out of it because of the way we do these things.

I also feel that 'stick' option is a bit paradox. If the old version is good for upgraders, this also means that it is good for -S users... And I think this "invisible" flag would cause more bug than benefit (developer forgets to revoke this flag etc.)

I see how this option could be useful, but as Nagy said, it would be more complexity, so potentially more problems and bugs, and as Aaron said, the current way of managing these at repo level seems good enough. So "won't implement" ?

Another distro using pacman might find it useful if their system works a bit differently to Arch. But I would close this with a "won't implement" and if another distro comes along wanting it then reconsider.