Comments by "LoneTech" (@0LoneTech) on "How Software Deals with Key Presses - Computerphile" video.

This is a little tricky. In layers which observe press/release events only, like many operating systems and programs, the key would appear still held. For a hotpluggable keyboard type like USB, the keyboard removal is a detectable event and should lead to automatic release of all keys that were held there. For a PS/2 keyboard, the key might appear still held but not repeating, as repetition can be done in the keyboard; many operating systems perform repetition in software anyway, and then it might continue to repeat.
11
It was not handled in hardware on PCs, but it was on Amiga computers (well, control-amiga-amiga was). On PCs it is handled by software, whether firmware (BIOS/EFI) or operating system. Microsoft's official excuse for training people to hit that just to login or unlock a machine is that it's always handled by the OS, which is nearly true (unless a program manages to disconnect the keyboard driver itself), but likely the real reason is that it would make other OSes appear less stable if you happened to hit it on the wrong keyboard.
7
Yes, shift keys get press/release events just like other keys. Since they're meant to be held they also frequently have dedicated lines (such as being outside the scanning matrix, or having dedicated bits in a HID report). In the OS level, they'll activate keyboard mapping states such as capitals for decoding other keys, but not decode to printable letters themselves. So a program waiting for text won't notice them, but a program looking at held keys will.
5
This is an operating system architecture question. Your program could be designed as a set of event handlers, and not actually have a running thread unless it is processing an event, but most operating systems dedicate one or more threads to any process, and one of those threads will then have the task of collecting events. It's essentially a pull architecture instead of push.
3