What is needed for a request to add an out of the box device_tracker for a certain device, in this case a (bunch of different) Nuki locks?
OMG + TG at best.
I would have thought you’d know the procedure by now 
I’m not too sure though if Nuki locks, which usually are installed stationary in homes, would be of interest as being discovered as general device tracker for all users, and your use case, of which I’m very curious to hear about, might be better off with a manual custom definition!?!
Indeed I know mostly. Just wanted to kick-start this for this device while being on the go.
The reason is because HA screwed up things long time ago (iBeacon tracker integration collecting foreign devices because there‘s no allowlist etc., really wild also from a legal perspective)
My personal attempt is to migrate away all the remaining devices to kick that integration - and OMG/TG turned out to be a perfect home for all those BT devices.
I could of course live with a custom MQTT sensor definition which gives an actual device_tracker entity in Home Assistant. I just never managed to find a way how to do that as those entities can usually only be created by integrations (or hacky custom components which is not the route I want to choose).
I really can’t comment on the HA iBeacon tracker integration, as I have never used it, but this behaviour is the very good reason why we do not auto-discover any old iBeacons haphazardly, but only selectively recognised, decode and discover specific devices which also broadcast in the iBeacon format - your BM2s for example.
You still haven’t answered my above question though - why would you want Nuki locks to be discovered as BLE Home/Away device trackers, when they are generally installed stationary in homes and the tracker status would constantly only be Home?
Or what is it that you are actually trying to achieve, which I might not have fully comprehended yet?
Just general status monitoring. Connection issues, dead batteries etc.
Then it is definitely not a BLE device tracker that you want, but a full-fledged Nuki lock decoder.
We have decided a long time ago that we don’t really feel comfortable creating decoders for lock which use Bluetooth in an unencrypted way, for privacy and security reason, and me personally not quite understanding how anyone could pout insecure locks on their home doors as with this case …
I really hope that U-Bolt has since made their locks more secure with firmware updates, and that Nuki also relies only on encrypted and/or securely paired communication protocols, as I don’t think you or anyone else really wants to broadcast the state of their front doors locks to all their neighbours or even potential burglars 
Any such paired secure communication is out of the scope of a Theengs BLE decoder, so your best bet is to look around which Nuki Lock specific HA integrations there are and which is best suited for your needs.
No worries, Nuki is tested and verified ever since e. g. by Certified Version 4! Nuki Smart Lock 4.0 – AV-TEST Internet of Things Security Testing Blog
Next to the pure existence of the lock you get zero information via regular BT broadcast, for this you need a secure application.
So if OMG can‘t do what the dumb iBeacon tracker integration does (providing a simple device tracker), I won’t stress this any longer here.
Good, as it is still is totally unclear what you actually wanted and what you did achieved with the iBeacon tracker, more than just being able to track a Bluetooth MAC address, which again would be a simple BLE device tracker, but which again would make absolutely no sense for a stationary device like a door lock.
So unless you can clearly and comprehensively state what you actually want, and what you did with iBeacon tracker, it really is best not to stress this and me any longer.