Please fix the combo box RowSource datatype binding bug.

The bug is as follows:
1. Create a table [Table1] with two columns:
- [NumberField], datatype: Number, Double
- [TextField], datatype: Short Text

Add 1 Row to the table:
[NumberField] = 10
[TextField] = "Some Text 10"

2. Create a combo box:
- Set the RowSource of the combo box to this:
SELECT NumberField, TextField FROM Table1;

3. Add a Button to the form: [cmbErrorExample]
Add On Click Event:
If Me.cmbErrorExample.RowSource = "SELECT NumberField, TextField FROM Table1;" Then
Me.cmbErrorExample.RowSource = "SELECT TextField, NumberField FROM Table1;"
Me.cmbErrorExample.DefaultValue = "Some Text 10"
Me.cmbErrorExample.Value = "Some Text 10"
Else
Me.cmbErrorExample.RowSource = "SELECT NumberField, TextField FROM Table1;"
Me.cmbErrorExample.DefaultValue = 10
Me.cmbErrorExample.Value = 10
End If

Now open the form:
Drop the combo box, you should see the one row with values:
10 | Some Text 10
Select the row - the value of the field becomes 10.

Now, click the button. The Rowsource should change to:
"SELECT TextField, NumberField FROM Table1;"

However, if the user has already made a selection as instructed above, error appers:
---------------------------
Error Occurred in Sub cmdToggleRowSource_Click of Module Form_Form1
---------------------------
Error The value you entered isn't valid for this field.
---------------------------
OK
---------------------------

Expected: the code should be able to programmatically change the Rowsource of the combo box.

Actual: Because the unbound field has had a numeric value assigned as a value, the programmatic change of the RowSource of the combo box to a text value results in a type mismatch that should not be happening.

This used to be possible in Access 2003, but in Access 2019 the combo box appears to change itself to be bound to a numeric data type, even though it is an UNBOUND field.

This is a problem when creating forms that change combo box data sources programmatically.

This URL contains a .accdb with a sample form that demonstrates the issue:
https://1drv.ms/u/s!AhezOlimTLoah-V27m77K4MRlU5loQ

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

Sizeable MDI forms in Access 2016 have a single-pixel border that is very hard to grab with the mouse.

The form borders show as a single-pixel whether the form mode is "no border", "dialog", "sizable" or "thin".

One work-around is to make the form a popup form, but if you make every single form in the database popup, you lose the MDI functionality and the ability to have a genuine popup form. When everything is on top then effectively nothing is.

This creates a serious accessibility issue particularly when combined with the fact that MS Access forms and controls don't resize correctly when the Windows text size/DPI is altered.

After update to Office 365 ProPlus 1808, a my customer start complaining about very unresponsive form in an application they have been using for many years.
I have been testing and checking for several days (with SQL Profiler, Wireshark packet sniffer and ProcMon), and seems the problem is reading %userprofile%\appdata\Local\Temp\JET8F62.tmp, which MSACCESS.EXE is doing a ReadFile Operation to. When the applications start to get unresponsive, many thousand reads are done to the same temp file. I have tried to change ODBC Driver (ordinary SQL Server v10, ODBC Driver 17 for SQL Server, V2017.172), I have tried to convert the .MDB file format to .ACCDB, I have tried to upgrade MSAccess 365 from 1808 to 1903. Also tried to run MSAccess as Administrator (in case of weird security settings) but no luck. Still same problem...
After about 30 minutes of usage, ProcMon shows about 600.000 events from MSACCESS.EXE, most of them ReadFile operations to the temp file. Each time the app get unresponsive, ReadFile operations events are starting to occur in ProcMon (several hundred per second). After ca 10-15 seconds, the ReadFile operations stopp occurring, and the app seams normal for a couple of seconds, but if the user move to another record in the form, the problem starts again... Also, when MSAccess is unresponsive, the MSAccess menu turns completely white (all icons etc disappear), and title of MSAccess Window shows "Not responding"...