Also, turnaround times from idea to final product can be insane at that level. These teams often have to accomplish in days what normally takes months. But they can pull it off by having every step of the design and manufacturing process in house.

The simple fact is that rules matter if and only if they are enforced effectively by a community. And power is the ability to direct and control that enforcement.

The international order has declined in the past one or two decades because the UN security council was hamstrung by the enormously powerful veto rights held by Russia, China and the U.S. This has slowly emboldened those countries to de-value the UN and pursue their own interests.

D&D has a strong narrative aspect when you look at the published adventure modules. There are usually plenty of characters to interact with in some way or another and some quests can be solved entirely by following the breadcrumbs offered up through them. But the DM needs to role-play all of these characters and do a lot of improv to make this work. This isn't so easy.

Also, combat in D&D is a slog. Whereas turn taking outside combat is rather fast and loose, the game turns into this enormous ceremony once the words "roll initiative" are spoken. The effect is that combat can take up a lot of playtime relative to the non-combat role playing, while often also leading to less overall quest progress per time.

If you want to be critical of the outcome on compatibility grounds, forcing a grind to increase technical compatibility is the wrong thing to ask for. That must necessarily always leave some people behind. The only honest alternative positions on that front are (a) the government issues the tech to everybody itself or (b) the government doesn't build advanced systems at all.

The German government offices rely on a lot of quaint-looking paper based processes, but they have one thing going for them: working through them can be done with pen and paper - tools that are available for cheap and broadly compatible. It's probably not such a bad thing after all?

The limited selection of attestation providers can be criticized for many other reasons, though.

Different TUs can be compiled with different settings for the contract behavior. But can they be binary compatible? In general, no. If a function is declared in-line in a header, the comoiler may have generated two different versions with different contract behaviors, which violates ODR.

What happens if the contract check calls a helper function that throws an exception?

The whole things is really, really complex and I don't assume that I understand it properly. But I can see that there are some valid concerns against the feature as standardized and that makes me side with the opposition here: this was not baked enough yet

Global variables in PIC shared libraries are really weird: the shared library's variable is placed into the main program image data segment and the relocation is happening in the shared library, which means that there is an indirection generated in the library's machine code.

Average computer owners don't really care about their machines, let alone understand them. Computers are appliances to them like their washing machines and microwaves.

Parts of the GC language crowd in particular have come to hold some false optimistic beliefs about how well a GC can handle allocations. Also, Java and C# can sneak in silly heap allocations in the wrong places (e.g. autoboxing). So there is a tendency for programs to overload the GC with avoidable work.

It is about the entirety of the product, not its parts.