Hi Albert,
Speaking of which, only the drivers should be affected by detaching /
attaching a detachable keyboard, and precisely, the drivers should handle things so that upper layers don't need to care about the keyboard attached/detached state (except very specific parts of the UI, e.g. to show the detached/attached state and/or pop up a software keyboard when the HW one is not here and keyboard input is needed). Most certainly "all daemons up to GUI" should not be involved IMO.
Actually, not only driver needs to know it. Kernel needs to correctly pass the info about what has happened to HAL (udev, etc.), then daemons reacting to attaching/detaching devices (dbus, *bus, systemd, running terminals, PAM, etc.) up to GUI (window manager must not reset the layout; all input methods like SCIM/IBus/uim must preserve all pressed states etc.; mappings of different long-running applications like widgets or icons in tray should keep their state; user shortcuts must not get lost; running applications should not reset any input streams to not interrupt the current functionality, etc.).
All these have to handle the interruptions in a way, that they exactly (!) set the full device state back to the state before interruption. They also need to support these interruptions coming very quickly consecutively (e.g. each milisecond).
Basically such interruption demands a full hot swap functionality, which is basically not present anywhere in the stack I described above (yeah, 99.99% daemons and applications count on the fact, that the initial state will not change during their runtime).
It's really extremely frustrating when an old USB connector looses contact for a milisecond and my external keyboard gets redected and all the settings are totally lost (in terminal a different keyboard and without my key bindings - which might be impossible to manually reset because of the need of root permissions; the same in X except for the root permissions; the same with all running applications; the same everywhere). An extreme case are security modules (e.g. YubiKey) or security SW demanding uninterrupted connection of a certain device (due to possible MiM attacks etc.).
Just my 2 cents from real world.
-- Jan