Code freezes like this are worst when there is no individual branching capability or local revision control, because that guarantees large commits.

... and because it used "if" instead of "assert", it made the null pointer arg a valid argument, making it a tolerable state of the running software, which displaced the locus of crashes far from the source of the issue. Moral of the story, use "assert" to make it crash as early as possible and debug THAT. You want to restrict the representable states in the software, not expand them by adding null checks everywhere.

In the same vein, on the consumer side we talk of admission control (which is just another name for "drop incoming messages") and throttling...

Another technique is to use the Least Significant Bits: indeed since pointers are 64 bit aligned, the lowest 3 bits are always zero, therefore it is possible to pack 3 bits of information there.

And there's a third technique in C++, which is to use placement new to morph an object in-place. This can be use to toggle between 2 classes with a boolean method, where one has this method return true and the other class has this method return false. This creates per-object state that really uses bits in the vptr to store this boolean state. Obviously this can be used with a whole set of classes to stores more bits. I have used this successfully to store values of refcount (each AddRef/Release using placement new to morph from RefCounted1/RefCounted2/../RefCountedN classes) to implement reference counting without a counter.

See https://www.pdflabs.com/docs/pdftk-cli-examples/

But really, the premise of using a shared map with concurrent readers and writers seems like a good generator of hard-to-reproduce bugs. IMHO shared-nothing (when feasible) is much easier to reason about, and possibly do periodic merging of thread-local updates, but I would avoid concurrent updates entirely (in particular if 2 threads race to update the same key... that goes to deeper design issues in the application).

My initial guess is that the text edit control has "select all content" set initially, so when you enter the 1st character, it's selected, and when you enter the following characters they overwrite that, essentially chopping off the 1st letter of the password (which is then incorrect, obviously). Unbelievable that this was never fixed (especially with IT-managed laptops that lock themselves very quickly).

income tax is progressive but tends to become regressive at the very top when individuals have control over what counts as "realized income". The ultra wealthy in fact don't pay so much tax (and certainly not their "fair" share).

What you say is true absent any tax optimization, alas there is such a thing, especially at the top. Also, see works of Zucman and Saez.