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.

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.

ULS was a pain and way too many people implemented it incorrectly but it did serve a function which we have lost. People who develop Access apps for others need a way to completely lock down the FE. The .accde doesn't cut it because users can still modify tables, queries, and macros. We need something that acts like the .accdr but which isn't a trick. I understand why creating an .exe is not an option but you should be able to create a "permanent" format that acts like .accdr but which can't be undone by simply renaming the file. That would actually encourage developers to create more shrink-wrapped apps that are sold to the public if they can be assured that their intellectual property is protected.