Both of those could be platform artifacts, nothing to do with what the Zigbee coordinator inside the hub is tracking.
I’m concerned if your hub accepted information from what should just be random noise in the neighborhood.
There are three possibilities as you describe the situation:
A) the hub heard the Zigbee join message, correctly went “Oops, not for me”, but incorrectly failed to tell the cloud to ignore it. That would be bad but fixable.
B) because this is a device that once was joined to that same ST hub and perhaps had never been deleted, and because zigbee devices have unique ids, the hub may have interpreted it as a rejoin request and then the new architecture logic kicked in trying to match it to an edge driver. That would actually be human error for not having deleted it from the old hub before trying to add it to a new hub with overlapping range. That’s an “Oh, yeah, we’ve all done that” situation—you just delete it from the old hub and start over. Or it could be a platform error, where a requested delete failed to complete, that can happen too. But the point is that if that device ID still had an entry in the Zigbee table, weird things could happen.
Also note that since devices that are in the Zigbee table can initiate a rejoin from their side without you having to put the hub into pairing mode, it would fit what you saw with the added twist of the new platform logic to match it to an edge driver.
C) it had been successfully deleted before and the ST hub actually tried to add a device based on a random join request to another hub in an overlapping range. That would be (from a network maintenance perspective) horrific, so let’s hope it’s not that.
So I’m hoping for B.
See if it still has an entry in the hub’s device table (not the cloud, IDE, or app, the actual zigbee data). If so, delete it.
Then if you want, try adding to the Dirigera again and see what happens this time.