No, the std::mutex is the reason you have a condition variable. Never mix std::atomic with std::mutex-and-friends, you are very likely introducing race conditions that way.

Another issue I heard, but I don't know enough about the physics of e-ink to know if this is correct, is that if you are at a gray level, the white and black particles are mixed and might exchange charge, thereby causing some particles to not move correctly anymore.

Maybe there are some weird situations where a host that just got its own IP address starts proxying for a third node that wants return packets to asymmetrically bypass the host?

The road to hell is paved with good intentions.

Some recent advances, like the Raspberry Pi Pico's PIO units, have made it possible to do things that MCU's couldn't do before, like emulating a ROM chip. But there are limits to what the PIOs can do.

If it comes to pure computation and not latency, you need some very specific use case before an FPGA becomes better than a regular CPU. Most likely when it involves massive parallelism and custom caches and interconnects. Although nowadays NPUs are starting to fill that niche.

For tiny boards in particular: getting experience and having fun.

Compilers can un-inline as well. In fact, since every function is defined in the header file, the static inline annotation means very little, it's more of a hint; the functions that were not marked static inline can be inlined just as well by the compiler.

One problem with -O3 is that it disregards any effects of the cache (and yes, ESP32s have a bit of cache memory). I recommend using -Os as the default optimization level, as it often has the same or almost the same performance benefits as -O3. Less cache pressure is beneficial, especially for bigger applications, and the smaller code size is of course nice on embedded systems that have limited amounts of flash storage. If you know some specific functions or source files are performance sensitive, you can use pragmas to change optimization for those:

    #pragma GCC optimize("O3")

Debian is run by volunteers, and I think Debian Developers would not like it if they would have to pay to work on it, thus there will be some aversion to (at least frontier) LLMs.

That's not the case. First, you can't really extrapolate from endorsers to all of the Debian Developers. Second, endorsers might not have looked at the other proposals at all, and the fact that they only endorsed one option doesn't mean they don't support the others. And you can also endorse an option if you believe it is a valid, useful proposal to add to the GR, even if you don't agree with it personally.

But most importantly, when Debian votes, you don't vote for a single option, instead you rank the choices, and apart from the given options, another option "further discussion" is always added to the list of choices. It's likely that many who rank the most permissive option first will rank the lesser permissive option second, above "further discussion", or they could even give options the same rank (if they really don't think one is better than the other).

A very good way to deal with this is to recognize that all infrastructure needs maintenance and periodic replacement. Once it is time to replace a road, that is when you change it to include bike paths, bus lanes and so on.

You need some foresight, planning, make new road designs part of law, and political will. Some countries have made this work very well.