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

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.

I purchased Office 365 Business so that I could use Microsoft Access. As it stand the application does not work as designed. When you go in to Form view you see limited fields. When you go in to design view you can see more of the fields. I've spent several hours with Technical support trying to resolve the issues with no success. The problem as explained to me is the Home Inventory template is not compatible with Office 365. So my thoughts is why is if available as a template if it's not compatible. I would like to see the issues with the template resolved.

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.