It was while revisiting some static initialization order issues with the spdlog log library that I finally noticed I could think of these things this way. It's somewhat sad that I'm engaging spdlog, which I mostly value because of its use in the BrainFlow library, a small MIT-licensed brain signal interface by a lone developer in Russia. I wouldn't be using BrainFlow if I could get myself set up with OpenViBE, a much larger LGPL-licensed brain signal environment from France, but with OpenViBE I get the chest contractions and amnesia and such more strongly, and then with the amnesia I forget it exists, and stumble on BrainFlow, and the rest is timelines. Anyway, BrainFlow inherits design flaws from its dependency on spdlog, which has static destruction order issues in its implementation, resulting in patterns of using static objects but having to jump through hoops to output log information in their destructors. The static destructor issues in spdlog are multi-fold, moreso for me because the C++ specification has had many new revisions since I stopped reading written text. Some of them relate to quirks of DLL unloading on different versions of Windows. I first made myself visible to spdlog on 2021-02-20, looking for details regarding the DLL unloading concern. Things happened and were raised by different people, time has passed. A new issue was opened for a more core part of things. Not much action. On 2022-08-16, tfiner made a comment more experienced than others, on the new issue thread, at https://github.com/gabime/spdlog/issues/1738#issuecomment-782632346 . tfiner basically proposes to redesign the parts of the library involved, rather than to address the issues in the current API. tfiner speaks in line with my own original concern when saying "It is an unusual library that can't be called from a static object's destructor deterministically and safely." Today, I had some casual interest in resolving this, not knowing of the new developments. Usually, I would go through all the options, pick the best one, bang it out, and contribute it. And I'm still used to assuming I can do this! Nowadays _all_ the options is more like ... "uhhh how many intergalactic amnesia bubbles do I have to send autonomous time traveling robots from in order to bring these things together, and what patterns do the autonomous time traveling robots need to collect before they unite?" which may make no sense to you but is hilarious and sympathetic for me when I write it. Another thing I notice is that it is again incredibly hard for me to consider, design, and write code, and this difficulty is in some new ways that I'm not expecting. When I experience severe coding trouble, I remember a number of years ago, when coding was even harder for me (although in different ways) and then how I returned to coding in some years between. This memory is always inspiring for me, although I'm not quite certain of how much to rely on it. Big large questions with the spdlog situation might be: - What is the best solution or solutions? - What is needed to implement it or them? - What are the details of the problem and its systems to find obscure options and obscure concerns? My usual approach would be to consider every possible option, and then pick among them. When it can take navigating convulsions to explore exotic, low-return options, part of me can get kind of angry at other parts of me, to spend my time that way. I'm never quite sure. But for thoroughness, I expect that continuing to try can make things easier. It can take a lot of intentional and ritualised repetition to get to that point. Areas I might need more information on might include: - Revisions of Windows that have DLL unloading quirks and the specific details of those quirks - Possible avenues present in whatever the latest C++ specification is that the project supports - The static construction and destruction rules specified by the standard, and separately the rules adhered to by every mainstream compiler the project supports - The preferences and norms of the users and developers of the project, and of experienced C++ programmers in general Ideally, there is a solution that retains backwards compatibility, but if the project is conducive to an upgrade that solves all the problems at once and deters future ones, then simply implementing an approach like tfiner's makes sense. But one can never know for sure without a thorough review. There's always a little nook of options that can yield a lot of fruit. Every hacker knows this.