Right now the size is not big enough in many cases depending on the number of records. Since datasheets are usually wide anyway, this can be easily increased.

On many forms I create, I include filtering fields at the top of the form, a filter and clear filter button and the datasheet below. If the user unclicks the filter on the datasheet, this causes issues as the filtering on the form above is not cleared at the same time because the main form does not know about the "unfiltering" below. If the datasheet view had a property that controlled the "filtered" button option. If disabled, just show the word filtered if it has been but not clickable.

Let us know when we can download it

Often times I want to be able to run a spellchecker on just a single textbox, of just a single row/record. The primary textbox might contain text while other textboxes on the same form could contain references that would not make sense to spellcheck.
Ideally, as part of the beforeUpdate event of either the textbox or the form, I could run the spellchecker and react accordingly.

Install SQL Express alongside Access and make SQL Server the default database format instead of ACE. With a SQL Server database Access could and should support all the features it currently supports with ACE. Integrating SQL Server in that way would enable a much greater range of features and use cases to be supported out-of-the box.

Many of the error messages could be more informative. Those that tell us 'it was not possible to xxxx nn records' could provide information in a table about which records had the problem - like you get with type conversion errors on an import.

Better control of datatypes when importing from Excel or linking to a worksheet.

Currently the import decides for you using the first few rows, so often you have truncated memo fields when the first few rows are less than 255 char or errors when the first few rows are numeric but later rows are alpha numeric.

When importing into an existing table the import should honor the datatypes in the table.

Several SQL Server / ODBC data types poorly supported. I have just found that NVARCHAR(MAX) is the recommended SQL Server memo field type but Access is inconsistent in handling this - text larger than 4000 characters fails to update.

When multiple forms are open and you go into the VBA IDE and then switch back to the GIU view, the object that was selected is no longer selected or the object that thew the VBA error is no longer selected. Furthermore, you can't just select the object from the tabs. You first have to select another object before you can select the one you want.

Bring menus back as an option. The story I heard was that MS Access had to go the way of other Office applications. The example was that Word had over 1,400 menu options and most of the tech support calls were to help people find the right menu item. Access is different. Most MS Access application have a limited set of menu options so the need for the Ribbon interface is overkill.

Add SwipeLeft, SwipeRight, SwipeUp and SwipeDown events at the form level. Tabs could support Swipe Left and Right to move to the next tab. Datasheets could use it to move in the grid.

Maybe this is too much to ask. Can we request to to evolve from VBA to vb.net? allowing us to take advantages of parallel executions?

In VBA if I want to change the .connect property to a server where I have no access, the tableDef.Refresh generates an error.
I would like to be able to relink from DEV SQL Server to PROD SQL Server before deployment even when I have no access to PROD

I have always wanted to be able to add appointments to Outlook via the link to the PST file using an append query.

One of the biggest problems IT Departments have with desktop Access is security issues. Microsoft can do multiple things to address these concerns. One of the most straight-forward is to make it easier to publish a runtime file. Access application administrators should be able to publish a runtime file as fast as they can publish a .accdb or a .accdt file.

Make Expression Builder available from Visual Basic Editor, as it used to be in Access 97 and before.
Currently it can be opened only from query design view..

It makes it much simpler to create applications if 254 column restriction is not applied like in Access. Unfortunately in Engineering system I can't avoid using more than 254 columns. Computer speed is not anymore a problem so why to have that limit.