Bluetooth LE - BluetoothLEDevice.FromBluetoothAddressAsync returns null after UnpairAsync() is called until the peripheral is power cycled or the RPA rolls over

Greetings

Here are the reproduction steps for this bug. I have an Ellisys trace and logs gathered using WPR that I don't want to post publicly, but can share with someone from MS.

1. Pair a Bluetooth LE peripheral with windows.
2. Observe that a new instance of the class BluetoothLEAdvertisementWatcher when started and stopped reports connectable undirected ads from the peripheral, which seems to cache the LE address originally used when the bond was established.
3. Forget the bond keys on the peripheral but not in Windows, as commonly happens with peripherals.
4. Scan and connect to the peripheral in Windows using BluetoothLEDevice.FromBluetoothAddressAsync() which returns a non-null value, then trigger the connection by attempting any GATT operation.
5. The peripheral will disconnect with no feedback from Windows that the peripheral reported it is no longer bonded, if GattSession.MaintainConnection is true it will keep trying to reconnect then disconnecting.
6. Alright, that's a decent heuristic that the device isn't paired anymore. Call UnpairAsync()
7. Create a new BluetoothLEAdvertisementWatcher or use the same instance, either way, scan for the device again. Assuming the device is connectable, which it is in this scenario, Windows will forward the ads to your application.
8. BUG - Using the address reported by Windows from those ads, call BluetoothLEDevice.FromBluetoothAddressAsync which return null.

It continues to return null until the peripheral's random address rolls over or the peripheral is power cycled so the address changes.

This is a major blocker for peripherals such as small medical devices or anything without a UI. I tried any number of variations of tweaks to how the API is used with no effect.

Is this a known issue? If not, I would like to assist in gathering details to get it fixed please, thanks.

I think Windows has a major gap in not handling the scenario gracefully when a peripheral forgets its side of the bond keys too - external user intervention is required to recover from this.