Consider downgrading VBA references to ALL Office product libraries
This includes a comment "This is by design. VBA references are upgraded but are not downgraded." which I have also heard from other Microsoft support staff
I differ in opinion about “by design”.
I feel that since these are references to libraries supplied by Office, and since the newer office application VBA environment “knows” enough to locate and upgrade ALL the office library references, and since the older office application VBA environment “knows” enough to locate and downgrade the library for ONE office library reference, it seems like it is somewhat negligent that the older office application VBA environment does not bother to take one more step and downgrade any other office library reference that it knows about and can find.
In the case of Word, Excel and some others, the user at least knows when they explicitly "SAVE" that some change could be made.
However, in the case of Access, the file is automatically saved without asking. So after Access 2016 opens a file, references to other Office libraries will be updated and thus “broken” for anyone using Access 2010 or 2013.
Suggestions related to VBA editor should be posted in the Office Developers User voice site here – https://officespdev.uservoice.com/
Closing this suggestion so you can have your votes back.
Mark Burns commented
This would violate the foundational precepts for the COM specification which make INTERFACE INHERITANCE work. The reasoning behind this is that FUTURE versions of an interface are allowed to SUPERCLASS the base class's interface (i.e. EXPAND functionality available through the interface - to add new features) However they are NOT allowed to DROP existing things from the interface as that would violate the defining precepts of interface inheritance. So, in practice for your request, the principle would apply in this way - say you have an app that was created for Office 2016 and you automate Excel from Access 2016 in that application. You use early binding and therefore have the Excel.Application.16 (or whatever the actual # is) referenced in VBA.
Someone wants to use that application on a PC that only has Office 2010. Since the actual reference is for the Excel.Application.16 interface (internally) in VBA, the Office 2010 Access VBA cannot find that interface and gives the classic MISSING reference behavior. It CANNOT PRESUME that the code in your VBA does NOT use API calls specific to the Excel.Application.16 COM INTERFACE class (or, for that matter the Excel.Application.15 version) and just blithely adapt the library reference to the (available) Excel.Application.14 class instead. This could cause unanticipated errors. MS chose LONG AGO to force developers (and, by extension, end users) to handle such COM Interface Versioning conflicts manually as there was no safe alternative, automatable means of handling this type of problem.
The key point for you to understand, here, is that the Excel library that gets referenced (in this example) in VBA is NOT "Excel.Application" but it is instead "Excel.Application.#" where the # is the particular "version number" of the interface to be referenced. This is by design, and is unlikely (to say the very least) to be changed at this late date.