If the client is using a RPA or Random Private Address, you can add the device's idAddr to the resolving list after bonding. When the security keys are exchanged, the idAddr is also exchanged. You can add this address to the resolving list and the whitelist. So, when then central's address changes after the first time, your peripheral will be able to resolve this new address(provided its RPA) and will allow the central to connect. If it is not able to resolve, it will not allow the central to connect because of the filter policy. APIs you will need to include:
However, this feature is a part of the Privacy 1.2 which is associated with Bluetooth 4.2. So you will not be able to implement this in Bluetooth 4.1.
Coming to your second problem, I cannot comprehend as to how/why it is happening so. Its behaving differently because of a breakpoint?
I do not think I can safely use Bluetooth 4.2 features as they will not be in most client devices (I'm not sure if support is even in Android yet). However even in 4.1 bonding does seem to be able to resolve the RPA because it continues to recognise the device. All I want is that information at API level so I can respond differently depending on whether the client is bonded or not.
I'm getting the impression I should not be seeking to block connections at all, but rather should lock down the individual characteristics to require encryption and therefore bonding to actually do anything. I need to do some more tests.
As for the quantum debugger, I've noticed this kind of problem a lot when debugging BLE. For example if you break in the callback and then single step you usually end up in an ISR you do not have source for.