I am of the opinion that we should leave the church in the village.
The fact is that Access is quite a complex (development) application that interacts with millions of possible dependencies that it cannot always influence itself. It is also a fact that Access as a development system (unlike some others) has been around since time immemorial and is just as alive today as it was almost 30 years ago.
The current main focus of the Access team must be primarily on bug fixing, or being bug free. New features are all well and good but not absolutely necessary. New features won't bring a single additional user to Access and won't keep a single existing user with Access (just because of that). Either it fits now (power, image, performance during development etc.) or it never fits.
I myself have developed two very large applications completely on my own using the capabilities of Access. The products are currently used by several 10,000 users daily (one of them is described at http://www.dokuwork.com).
What is really important for the commercial use of Access as an application (runtime) with end users is that Access runs stably and works reliably. Overwhelmingly, this is the case.
Hindering is the monster bug (@Michael_Aldridge knows what is meant by this) and hindering when using complex Access applications is the 2 GB RAM lock (LAA). For example, I don't understand why when doing an Office/Access update, you don't just evaluate whether or not the LAA flag is already set in Access.exe.
(Only) in the case that an intervention was already present (LAA = active) it is automatically set again in the Access.exe during the update process. This avoids any discussions and the use of LAA is the sole responsibility of the Access user.
Many greetings from Bensheim
Stephan