I definitely recommends that you start learning about the LL(k), LALR, and perhaps even Earley Parser algorithms. I am assuming you have picked up a little bit on LL(1) parser and some basic lexer, so mastering the parser algorithms are basically the next stop for you.
Once you get the grasp of those things, you are well on your way to designing a programming language.
It's far from a full alternative to LaTeX, but it's a nice to have a "lite" version of it.
I concur, there was a few problems that might come up on various platforms like Windows not implementing C11 standard threads and other stuff, you would instead use TinyCThread library that works like a polyfill.
All problems and challenges are workable, if the problem with Debian is out of date library, you could set up CI/CD for release build that rebuild your software when update occurs and static link the updated dependencies.
Back to your point, if they didn't design their code and architecture to be multiplatform like in C, they need to re-evaluate their design decisions.
I would spend it on language translation basically, paying someone to translate international documentations on things that aren't documented in USA no matter where you look.
It's incredibly difficult task to master/learn an old technology or an old concept that aren't documented well. For an example, parser algorithms are very well known for being too verbose and unnecessarily over-complicated in documentation, if you ask anyone you know in the programming community, for the next 100 people, they wouldn't know how to implement LALR parser or Earley parser even if they graduate from university with a computer science degree.
One of the way I use to learn a concept is writing a full manual of it in LaTeX in a way that I am explaining every single aspect of it to a layman and how it can be implemented in every way as well as providing examples in C code forms. It's a bit interesting that you sometime learn better by trying to teach it to a made up audience when writing a manual.
Example page from a book I'm current writing in rough draft:
spoiler
I think it's asinine to ask the developer who contribute to your project, literally taking the time of the day writing the code and submit PR to your project, to pay money to you.
I wouldn't even bother contributing to the project at that point.
This is not the first time it happens with Dotnet Open Source packages, there are some pretty funky things going on namely:
Imagesharp (They re-license from Apache 2 to something like Community/Commercial licenses and threw a huge fit over it)
Fody (It expects the software contributors of Fody to be a patron.)
It just rooted back to my frustration when I was trying to fill in missing implementation details on projects like Skia (at the time it lacked support for Vulkan.) My very fundamental core belief is that for core libraries like say, Skia, Neural Net Framework, and other crucial projects like that should offer a way in C API that allows every type and implementation to be extended upon by any other language that can interface with C API by providing your own VTable or whatnot.
One of the approach I do for my GUI Toolkit written in C (specifically on Linux to replace QT and GTK) was making a single inheritance object oriented programming in C.and if you insert the base class type structure at the top of your custom struct type and provide your own VTable for those objects, you can readily extend the underlying library natively in whatever programming language you use assuming it can talks to C API in a complete sense.
Let me know if you want a demonstration of this, I would be happy to find the time to set up a small sample to give you the idea on how it's done.
And I am also aware of the criticisms on those approach, verbosity of attempting to implement object oriented programming in C is kind of absurd and the API coverage would balloon. That is largely why I work on a Compiler-Generator Framework specifically to address the challenges by allowing me to add dialects on top of C Language such as generic, object oriented programming, and various dialects. I brought C closer to C# in term of syntax and features and at the end of compilation, it still produces readable C language code output and it also generates what I called an FFI-JSON. It's essentially a JSON file that describes all of the types used in a C project, the sizes of integers/floating points, structure types and it's fields/offsets/sizes comments, and function declarations. It's done in a way that you could read the JSON file and generate your programming language binding library saving you weeks of work.
I don't think so on the extensibility aspect alone, some of the Rust syntax/trait does not map well to other languages when other languages attempts to extend Rust library. I write C code in a way that it would be extensible from any languages.
Yep, biggest reason why I chose C language is Foreign Function Interface. Code you write for C is more than likely to be usable in just about any other languages.
Yep, and if open source licensing could be revoked on a whim, you can imagine the chaos that ensued. That would be my understanding as well, old version that have MPL license is perfectly fine to fork off, newer version might not be as it is under a different license. One of the reason why I liked Apache License is that it have make it explicitly clear that it's irrevocable whereas MPL it is operating on an assumption that it's not revocable. The most fundamental problem with the legal system in USA is that no law is "set in stone" and leaving things to assumption is open to reinterpretation by the judge who may have sided against you. (Hell, Google vs Oracle on Copyrighted API is still on case-to-case basis, so take it as you will.)
Disclaimer: I am not a lawyer. I just share what I learned from Legal Eagle youtube and few other sources.