Also Ireland, Norway & Sweden.

1. do not use ANY company resources. This could put you at risk of theft.
2. do not do it on company time or make it look like it’s on company time. See point 2.

Did you mean “See point 1.”?

I mostly agree with you, but this is not quite true:

XDG implementation (which is also only used as a fallback when the three DE-specific implementations fail, even though all of them actually support XDG so having separate implementations is pointless)

Yes, the DE-specific implementations is pointless (as far as I know, I use a WM), but the XDG implementation is actually used first, and the function returns true if any impl returns true, like xdg() || gnome() || gnome_old() || kde().

rework the code so that there is a difference between “this DE wants light mode” and “couldn’t figure out of this DE is in light or dark mode” - both of these are now represented by the “false” return value.

This isn’t that bad? Yes, having an enum with three variants would be better and more readable, but the code just defaults to light mode if nothing wants dark mode, and prefers dark mode even if separate impls want both light and dark mode.

With multiple impls, you have to resolve conflicts somehow. You could, for example, match on current DE/WM name, only using the current DE’s impl, defaulting to XDG, avoiding the problem entirely or just use first impl that doesn’t return “default” or “error”.

I don’t like AI generated code, having reviewed some disgusting slop before. But it’s better to criticize the code’s actual faults, like the incorrect impls (which you listed) or failing the Linux CI.

How do you usually do that?

Do you create a negative of the model digitally or take a mold of the printed parts?

What kinds of human-friendly materials do you use? And do you need any special equipment for it?