Which has its own unexpected bug in that the extended deadbolt can damage the wood frame and/or trim. Or perhaps the sensor you use to determine the door's state (open or closed) is positioned on the hinge side in such a way that it's triggered when the door is kept open with the deadlock extended. It's close enough to closed that the sensor gets triggered, and you--I can't help myself--open the door to the possibility that your system falsely represents the door as being both closed and locked.

This stuff can be hard, and sometimes, you just have to refactor later on instead of trying to nail down every possibility for the model, despite trying to figure out likely issues in the near-term. In which case, the goal is to keep in mind that data models will eventually change over time, and consider how that knowledge might change what you're writing now to make that process less painful.

> Which has its own unexpected bug in that the extended deadbolt can damage the wood frame and/or trim.

It doesn't. The data is correctly representing the state of the system. Your "bug" assumes a lot of things about the environment, any of which may or may not be true depending on the specifics where the system is running.

> Or perhaps the sensor you use to determine the door's state (open or closed) is positioned on the hinge side in such a way that it's triggered when the door is kept open with the deadlock extended.

Again, an implementation problem. The sensor was installed in a way that's incompatible with the underlying system. Can it be fixed by changing the data model? Unlikely. In fact, I don't think it can be fixed at all. If the sensor lies, there's nothing the underlying system or the data model can do about it, especially if it's a binary sensor like the one described.

If the deadbolt was installed in such a way that it never crossed into the door frame but rather only moved inside the actual door, would you consider it a bug in the lock, the deadbolt, or simply bad installation?