1a. You can simply use the exact commit that the patch is for rather than constantly updating. If you are going to constantly update, you need to either wait for patch authors to update their patches, or learn how to resolve merge conflicts yourself. Patches being incompatible with each other? That's going to happen no matter what. Plugins can be incompatible with each other too. If you are referring to git not allowing you to patch, that's because the documented commands and options on Intersect's documentation website only cover the absolute basics, meant for people who had never interacted with this stuff before. If one is actually ready to resolve a merge conflict though (requires an extra argument on git am), they would look for git's documentation for the command and find what they're looking for immediately.
1b. Version control software is complicated, but it also does a lot of the work that you would otherwise have to do in order to accomplish the same tasks. It's something to learn. Having to resolve merge conflicts is frustrating, sure, but it's also inevitable if I want to be collaborative. Having to clean up after cats is frustrating, but it's inevitable if I have cats. Having used version control for years and having not used version control for years, I can say with certainty that I prefer the aid of git to trying to manage my code like I'm writing an Untitled-Final-Paper-Final-Draft-v3-DEFINITELYTHELASTDRAFT (2).doc.
2. Plugins and extensions... not an easy system to write! Most of the code isn't well documented, you're right. But most of the documentation that would be added will still not say "here is where you make your changes for X feature that you want", that's something that needs to come from experience, which is the result of investing time. A lot of it. You're not forced to use the patch system. You could make modifications by yourself instead of getting low-cost if not free help from other users.
3. Monogame is actually not extraordinarily limited. It just doesn't plop down what you want in front of you without research. It's got a lot of barebones functionality, it is a framework after all. JC writing some rendering code using VBOs is proof that it really isn't limited to just "blit this sprite here".
Since JC replied in the middle of me writing this I'll respond to his post now.
Like I pointed out, VBOs have been used, shaders too and more can be added.
In case anyone was thinking "SFML" and "advanced functionality" in that order without "does not provide" in between them is sadly mistaken. SFML is horribly limited and very non-performant at the scale that something like Intersect needs. The "this is not advanced" is literally in the first letter of "SFML" which stands for Simple. What SFML allows is for you to interface directly with OpenGL in order to do all of the VBO and shader magic needed for performant code for intensive drawing capabilities that it doesn't really give you the ability to do itself. With Monogame you don't have the ability to use OpenGL directly, but it does give you access to VBOs and shaders so it's not like it's hanging you out to dry. But both of those things are complicated features and by their nature are difficult to use. Having used both of them in OpenGL myself, I would argue that anyone arguing that VCS is too complicated is in for a reckoning if they thought "advanced functionality" was anything less than "complicated".
4. Personally, I think the code base needed to be improved further before going open source. Realistically speaking though, there were 3 developers with access before. All of us have jobs. All of us have lives. Our jobs and our lives come before working for free on a code base that you are not being forced to use. Many of the forum members were close to rioting because the source took 3 years to release after I joined, and I joined to speed it up. Ironically, my joining probably slowed the source release down by a lot, but then the claim that it was rushed (because the code was a mess) would have been much more true.
5. There are rules. Users are supposed to abide by those rules. Don't complain that people are doing their jobs if you don't like the rules, you should get public support for amending a rule instead.
6. If we were in the business of selling licenses for the code, the license would be more restrictive not less. Notably: Instead of being allowed to compile the client and share it without source code, and being allowed to share the server/editor with their source code provided as well, you would only be allowed to publicly share a compiled client and you would not be allowed to share the source, period, or that would undermine selling licenses.
7. There are 0 engines with advanced features that are truly non-programming engines. You might think "how about Unity or Unreal?", well: they're both programming engines. You can drag and drop all you want, but at the end of the day for any real customization or advanced functionality someone has to write code. Whether you buy it pre-written, write it yourself, or pay someone else to write it custom for you, someone wrote code. Even doing advanced things in Game Maker required at least basic scripting (or spending eons in the visual code editor).
8. You don't have to.
9. No documentation on a code base this large is going to tell you what you want to know before you even know what it is you want, at least not when it's written by 3-4 people over the course of 5 years in their free time.
This would have made a fine end to what is ostensibly a negative rant.
The engine does need a lot of work, you're right. And thank you for all of your contributions towards improving the engine.