The fundamental problem seems to be that your current code is not well factored out.
I think a possible approach would be to first refactor your project so all calls to A4 are cleanly wrapped by some middle-level wrapper functions. This is the most work, but it is valuable in itself since it will clean up the code of the project and make it significantly easier to update your code later. Then, replace A4 with A5 in those wrapper functions functions. At this stage, the upgrade will actually be not so much work at all.
We're well-aware of this, and we are slowly working towards a goal of processing all of these events through back-ends, but it is a very time-consuming process. Sure, it would be lovely if we had a huge staff to just jump in and refactor everything, but we have four people working on it in their spare time, as a hobby; so, it takes time.
I concur that it should have been done years ago.
Is there a reason you need to upgrade at this time? It may be worth a grain of wisdom: if it ain't broke, don't fix it. Is it feasible to write a compatibility addon that registers all events and tracks the state of everything in an A4 API? I don't know. I don't imagine anybody is going to go that trouble unless they themselves need it. Perhaps this is a project for the OP to attempt.
The reason is that on Windows, ag4 programmes have numerous graphical issues that are nearly impossible to resolve. We have fixed some of the most fundamental with care, but there are others that simply cannot be addressed; and in the future, as more and more legacy elements are stripped from the OS, it becomes increasingly impossible to maintain support.
On the Linux front, there are also a variety of sound issues that we have encountered, and I am not qualified to deduce the cause thereof.
The most critical question is: Should the burden of making the newer version of allegro backward-compatible be placed on the user?
I think that this is somewhat short-sighted. If ag5 was developed with backporting in mind from the onset--this was dropped early on--then we would not be discussing it now; but it certainly makes sense to have this as a capability.
Otherwise, you are just saying, make a wrapper for everything, at which point the user may as well use a newer model, or just use OpenGL. Allegro's popularity clings to legacy applications that use it. Now that those applications are breaking on modern operating systems, it is worth considering fixing the root of the issue, rather than saying that every single application needs to be refactored.
Ultimately, the problem is with companies like Microsoft, who drop support for drawing modes, or other core UI components, and expect everyone to upgrade. When you have a userbase that is updating to the shyte that is Win 10, and your software breaks because MS kill compatibility layers, you can't just jump on a rewrite and expect everything to go smoothly.
This is precisely what has happened on Win 8+, and TBH, what happened with Allegro 4.9. Perhaps it would be better to work on polishing 4.4x and just continue using it, but that is also a short-term solution .
Please understand that I don't expect a back-porting layer to be added to ag5. It should have been there from the onset, but it would be damned nice to have at this point, especially if you want to convince users to update to the newer lib without needing to fully re-write first.
This kind of thing allows the programmer to slowly adapt and merge a codebase to new ag5 stuff, without breaking the whole ball of wax and taking two to three years to do the conversion with zero updates, or releases in the interim. It is worth considering, as a future goal, at the least, IMO.