It has nothing to do with OOP. The design we're talking about is blind firing events at the in-focus window, and the in-focus window is being changed unexpectedly. The problem is loose coupling between the parent<->child. If the child window (PUK entry/pin reset window) knew the parent's ID and fired the dismiss event at that ID this wouldn't be possible.

Even the fix they implemented is poor: The child is STILL blind-firing a dismiss event, but they just told the lock screen to ignore dismiss events from the PUK entry window. Instead, the fix should have been to stop blind-firing events at whatever happens to be in-focus. They've added more complexity rather than fixing the poor design.

Sure, but it’s a race condition that could happen in a functional language, too. FP has an analogue to a class called ADTs, and you could have the same bug using those

Again not really, somewhere, something send a signals, and outcome of that signal depends on UI state. The problem is a lack of qualified signals and validated state changes, whatever the programming model used, if the logic is «remove topmost screen without any context check», you'll end up with this issue.