Look, you and I may have sane ANSI 16 colours, but it’ll be a very significant fraction of people that don’t (and almost no one will customise the next 240 colours). Remember things like that there’s a distressingly high chance that blue is almost invisible against black, and even bright blue’s contrast is commonly much too low—to say nothing of the limited palette range.

But what this program is doing is using termenv’s HasDarkBackground function to decide whether the terminal is light or dark, and is then specifying RGB colours. It’ll try to guess whether to use 16 colours, 256 colours or 24-bit colour and do some kind of mapping down if necessary (which I bet this app makes a total hash of, probably not having chosen the colours carefully). But the way it figures out the terminal’s background colour… ugh. Some terminals will support it, but for many it’ll fail and just assume black. Looks like on unix you could set an environment variable COLORFGBG to override this, https://github.com/muesli/termenv/blob/6bb55115565c27f4cc681..., but if you’re on Windows, tough luck, apparently you’re not allowed to have a light terminal (which you can get in Command Prompt by running `color f0`): https://github.com/muesli/termenv/blob/537e36cb0472a69a3c828....

The simple fact of the matter is that there are no particularly good solutions for handling colour in terminals if you want the colours to cohere and naturally map to real-world colour understanding, which is what something like this would prefer to be able to do. Things are just barely OK if you just want colours with no inherent semantics.

So… yeah, might be nice if they used the 16 colours, but I can readily understand them not doing so, and if they did do so, although it’d make it better for some, it’d make it worse for others. Where does the balance lie? I dunno.