Word Interop is a nice solution, yet very slow (comparing to OpenXml) and unreliable (we encountered that if a user clicks Ctrl+C to copy something, whilst Interop is running in a background, generating multiple documents, its content will be pasted onto one of those documents, although the user intended to paste it somewhere else) . There are 3rd party solutions to save as PDF from OpenXml, yet they do not render correctly our relatively complex invoices (header with image and table, footer with table and so on), so for now we ended up to generate them all as docx and then run Word Interop from a server to convert them into pdf, using SaveAs2 method.

It's been over 20 years since the VBA IDE was created in its present form. MS has since created a number of modern and efficient development environments. Even if the VBA environment has long been referred to as outdated: it is simply the everyday reality for the majority of professional Office developers (especially all serious Access developers). I can not imagine that it lacks capacity to MS to bring the VBA IDE into a more contemporary form.

To insist that it would not be worthwhile to invest in an improved IDE, is roughly as if an automaker refuses any further developments in the wheels for 20 years, with the note that they would someday replace all wheels by air cushions.

I am thinking about things like "real" IntelliSense (comparable to that in current Visual Studio languages), extensive auto code completion, syntax checks that support the coder and do not hinder him/her, a much better integrated help system, refactoring tools, etc..
In other words: Not a newly decorated IDE, but simply an up-to-date developement tool like those in modern IDEs (Visual Studio, Eclipse, NetBeans, IntelliJ IDEA etc.). I do believe that this would not be "old wine in new bottles" but a valuable "productivity tool" for all Office developers.

Word Interop is a nice solution, yet very slow (comparing to OpenXml) and unreliable (we encountered that if a user clicks Ctrl+C to copy something, whilst Interop is running in a background, generating multiple documents, its content will be pasted onto one of those documents, although the user intended to paste it somewhere else) . There are 3rd party solutions to save as PDF from OpenXml, yet they do not render correctly our relatively complex invoices (header with image and table, footer with table and so on), so for now we ended up to generate them all as docx and then run Word Interop from a server to convert them into pdf, using SaveAs2 method.

In the Access VBA reference (the Access Object Model documentation), please include the version in which each feature was introduced. That is, on each page describing a particular Object, Event, Method or Property, it would be useful to know in which version of Access it was introduced. That will make it possible to design in one version of Access and know that the code will run on an earlier version. Right now, the only way I know to do this is to test the database on an earlier version and find the components which aren't available by trial-and-error.

Other object model frameworks - and I'm thinking Apple here - provide this information. In fact, in the Swift compiler, used for iOS and macOS development, you'll get a compiler error if you use a feature that isn't available in the version you are targeting.

'~~~~~~~~~~~~~~~~
VBA Native line numbering
'~~~~~~~~~~~~~~~~
Adding line numbers is something that is a pet peeve. Line numbers should be Native and error trappable by default without having to add them manually.

'~~~~~~~~~~~~~~~~~~~~
VBA Accessible Call Stack
'~~~~~~~~~~~~~~~~~~~~
A way to read from the call stack, function/sub names in order accessed, times accessed...etc

'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VBA Custom Toolbars to allow custom Macro/Function Calls
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If I could add my ow custom functions as a toolbar button and have my toolbar exportable and importable for others to use. As opposed to a full Add-In.

'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
VBA button and/or right click to open SQL Editor
'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Frequently I need to use an SQL editor to evaluate or build a SQL String and it takes time clicking through to a query then changing that over to an SQL editor screen.
This could be eleviated with a quick access button or right click method from ANYWHERE. Almost any commandbar could benifit from this added functionality.

'~~~~~~~~~~~~~~~~~~~~~~
VBA Higher Level Access
'~~~~~~~~~~~~~~~~~~~~~~
BeforeDatabaseClose() event Please!

Collection level events that provide information about groups of entities. An example would be a public onEntityOpen(byval ObjectName as String) Event that fires for all objects of a certain type.
So Before a form/Report etc opens and runs it's own onOpen event you could run a higher level procedure to capture or set data without having to add any code at all to the forms onOpen Procedure.
Obviously it would know very little about the object being opened but none the less I can see uses for such a procedure.

The VBA editor with two dropdowns at the top, one for object and one for procedure, is fine, I suppose, for creating procedures (though I never use it). But it's a pain in the butt for going to an existing procedure. I never use it for that either, since it's easier to just do a Find on the procedure name you want.

I would like a SINGLE LIST of all current procedures in the module, so as to be able to easily navigate between them. The list should be in the order the procedures are in; or modifiable between that and alphabetic.

This could be in addition to the current two-list system, so that could still be used for creating new procedures.

When working in the VBA editor, I oftentimes inadvertently insert a character into my code. Perhaps I do Ctrl+S to save, but, for some reason an S gets inserted. Or Ctrl+C or Ctrl+V. Oftentimes stray characters find their way in.

I'd like a button on the toolbar to lock/unlock code from edits. Code is initially locked when editor is opened. Nothing can be changed. If I want to edit code, I just click the button on the toolbar, do my edits, and then click it again when I'm done.

If the VBA editor is closed and reopened, the code is automatically locked again. Thus, when done with edits, one can just close the editor to relock the code.