Opening/using forms that contain ActiveX controls, notably "Microsoft TreeView Control, version 6.0" cause Access to crash since at least version 16.0.11727.20210 on the Monthly channel. No versions in the Semi-annual (Targeted) channel seem to have this bug (yet).

The forms affected usually crash within moments of opening, but occasionally will work to some degree for several seconds.

Faulting application name: MSACCESS.EXE, version: 16.0.11727.20210, time stamp: 0x5d0d79e6
Faulting module name: ntdll.dll, version: 10.0.18362.1, time stamp: 0x9bbcb4a9
Exception code: 0xc0000374
Fault offset: 0x000df8cd
Faulting process ID: 0x50d4
Faulting application start time: 0x01d52cbe9164d25e
Faulting application path: C:\Program Files (x86)\Microsoft Office\Root\Office16\MSACCESS.EXE
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report ID: c7ada4ee-be96-4c9d-ade3-47beaddc78d3
Faulting package full name:
Faulting package-relative application ID:

Versions we've tested that experience this bug:
16.0.11727.20188
16.0.11727.20210
16.0.11727.20224
16.0.11727.20230

Versions that work fine (so far):
16.0.11328.20318
16.0.11629.20246

We're using Group Policy to block the versions with this bug and instead installing 16.0.11629.20246

Computer Configuration > Administrative Policies > Microsoft Office 2016 > Updates > Prevent Office from being updated to a specific version
Enabled, blocked versions:
16.0.11727.20224:16.0.11629.20246|16.0.11727.20210:16.0.11629.20246|16.0.11727.20230:16.0.11629.20246

This Control would have a Modern Appearance that we see on a lot of Websites using the Bootstrap technology. When the User resizes the Application, it would respond and collapse to a hash icon of some type.

This Control would be Table Sourced, where the Developer could enter Custom Search Terms and then map it to an existing Form Object. A default could be set to inherit the existing Custom Category, or inherit the Parent Child Navigation Buttons on a Navigation Control. The Developer could Customize from there. The Possibilities are endless.

The built-in Navigator exposes too many objects to the end-user and is somewhat confusing to them.

I feel that if we have a Tree Control of a Modern Touch and Feel, where the Child Items would flow out as the User hovers their Mouse of the Parent Node.

Well with the recent push of 64bit Office and the problems that arise by the lack of the usual .ocx maybe its time for a step forward....how about Open Source the usual suspects like MsFlxGrd and the alike...its a fact that you have some brilliant controls over 20 years old that alive and kicking in 32bit but not in 64bit and A lot of developers are forced to get stucked in 32bit because they just work and they provide unparalled functionality ....so if you really want to push the 64bit and for any reason you can't develop the 64bit equivalents of these controls maybe you should leave it for someone else....
I am pretty sure that if this comes with a price bonus...64bit Access will be fully functional in a mater of months

The Visual Basic editor should have an auto-save option. Code doesn't take much disk space, so this should be a default option (just like Word has an auto-save function). A couple of times, I lost a great deal of code EVEN THOUGH I SAVED IT, when Access crashed. Obviously, something didn't work with your Visuals Basic save function, as I lost my changes. That needs to be fixed. Nowadays, I'm copying my code to another text editor, just in case Access crashes and I lose my work.

You should have a recycle bin in Access for deleted tables. Upon exiting Access, you can they query the user as to whether they would like to clear their recycle bin. I accidentally deleted a table once, full of data, and had no way to get it back. Surely, in this day and age, a recycle bin for database objects is obviously useful functionality.

Your undo functionality should be better. I should be able to undo up to 100 steps, and then also be able to redo those 100 steps.

When I use a subquery in a query, I expect the outer query to only work on the results of the subquery. However, today, it appears that the outer query (the WHERE clause in particular), is not being strictly run on just the results of the subquery. Instead, the join in the subquery appears to be being ignored, and the WHERE clause is run on the much bigger dataset of the subquery minus its join. This is counter-intuitive and probably incorrect. Please fix this. I had a subquery that only returned two rows, but it appeared Access was performing an outer query function on the subquery without its join which happened to be millions of rows--it was very slow.

Sometimes CTRL+BREAK or ESCAPE doesn't work, even when Access says you can press CTRL+BREAK or ESCAPE to stop a task. I keep on running into this problem. I suggest better interrupts are programmed into Access that interrupt processing say every 30 seconds to listen to any interrupting key presses that have been made, so execution can be stopped. Fairly frequently, I'm having to crash out of Access to recover control of my computer. Even sometimes, I have to power off my computer completely (without a proper shutdown), to recover control of my computer. These should be simple things for Microsoft to do, to program interrupts for query execution, CTRL+F searches in datasheet mode, column sorts in datasheet mode, and other such things.

When running queries that invoke VBA code, sometimes I can't stop them very easily even though I am able to interrupt the code by pressing CTRL+BREAK. I enter debug mode, choose end execution, but then the code is run again (presumably for the next row in the query). It can be very difficult to get out of this loop-like scenario. Sometimes, changing the code in a function or subroutine procedure such that it is exited as soon as it is entered works to get out of this loop-like situation. However, sometimes, this doesn't even work. This should be fixed. If you gave the user the simple option to also terminate the query, alongside the VBA code interruption, then probably this would solve the problem.

Sometimes when I run a query, it appears to finish but then also appears to not have finished. It's almost as though there is some background processing that carries on after the end of the query. During such time, I'm largely unable to use the Access application. What is happening? It looks like there are some inefficiences somewhere. The query results appear but still Access is busy doing who knows what.