Down that path lies passing 60 parameters to constructors and grotesque contortions just to avoid using a global here and there. All of your code because harder to read, harder to understand, and harder to maintain.

You're comparing using global variables, to... writing terrible, terrible code....

How about you don't use globals, and *gasp*, also don't write terrible code?

Your OS syscalls are, for all intents and purposes, services/singletons.

And they provide a service to the EXE as a whole / their mutable state is owned by the EXE as a whole, so they don't have a choice but to be global (to the exe).

Development services such as a logger can argued to fit into the same category, so can get away with using global state.
Almost everything in a game code-base, does not fit into that category... and no, the alternative is not grotesque contortions and passing 60 parameters everywhere...

I am seriously tired of dealing with the cognitive overhead of dependency injection frameworks

I've also seen some pretty terrible global service locator frameworks. The problem there is bloated frameworks and bad "architects"

Error 2 error LNK1120: 1 unresolved externals E:\WORK\InLine2D\InLine2D\Debug\InLine2D.exe 1 1 InLine2D

Anyway, back to the OP's question.

Whenever you're trying to do something in C++, it's always a good idea to look to see how the standard C++ already does it, because there have been a lot of expert input into the design and implementation of the standard C++ library.

In the standard C++ library, there is a global console logging object with a set of overloaded and templatized functions for inserting into it. In fact, you're trying to create a similar Java-style singleton class to wrap the standard object that already does exactly what you need, except not in the style a Java develop mey be accustomed to, with static member functions returning object instances that are used to invoke instanced functions with overloaded procedures for combining formatting and streaming functions.

In the C++ standard library you will find a set of global logging stream objects that are designed to be instantiated on first use: std::cout, std::cerr, and std::clog. They have an accompanying suite of overloaded and templatized functions (operator<<()) that perform manipulation and insertion into those logging streams. They have already solved your problems, consider using them instead of wrapping them in your own problematic code, or at least examine their design and emulate it yourself.

The C++ standard library logging objects are designed to be extended not only by overloading operator<<() for your own types but by replacing their streambuf to give you control over things like final destination or setting categories and severities. Notice the post linked to there was addressing pretty much exactly the same topic as this one, and is dated 2006. The aswer is still completely valid over a decade later.

I've also seen some pretty terrible global service locator frameworks. The problem there is bloated frameworks and bad "architects"