If I had ever thought about it, perhaps I was subconsciously aware. The thing is, when working with Windows applications, my approach is generally to accept the way Windows works without trying to re-engineer it. Call it lazy, or maybe call it expedient. I just don't worry about it that much, preferring to look for solutions that fall within the areas over which we do have some control. In this case, for example, I'd first consider other layout approaches as suggested above. It may well be that a compromise is the best available outcome.
That said, if you want to dive into managing behavior of Windows, perhaps via APIs, there may be a desirable cost-benefit ratio for this particular scenario. The fact that such a solution doesn't seem to be well known suggests it's not easy.
On the other hand, one of the things being discussed by the Access team for the near future (well, one can dream) is support for Large Monitors and some degree of responsiveness for Access forms. By that they mean increasing the current 22 inch size limits on forms and some ability to scale controls as forms are resized. I think it's far to early to say what that might eventually look like, but it is under consideration.
Finally, there is a common assumption about the costs of software development, called the 80/20 rule. It refers to the fact that you'll invest 20% of your budget on the first 80% of planned functionality, and 80% of the budget on the last 20% of functionality. It sounds like you are, essentially, at a 95% level of functionality already, which means the remaining 5% is going to be the most expensive part of the project. And that's where you have to step back, take off your developer hat, put on your project manager hat, and decide if that cost is worth it.
Someone, I believe Colin, suggested looking at other, non-native controls, i.e. ActiveX controls, to get the remaining 5% functionality you need. It might also be worthwhile to look into whether you can use Windows API functions to manipulate the scroll bars.
