[FEATURE] Allow authors to define incompatible projects

[SalmonSnakeD]

Please confirm the following.

• I checked the existing issues for duplicate feature requests

What parts of Modrinth is your feature request related to?

• Modrinth App, Modrinth.com website, Modrinth API for developers

---

The main idea

The battle of incompatible mods and other project types has been a problem ever since the beginning of modding. Modrinth could help a lot with this by allowing authors to specify a list of incompatible projects for each version of their own project, which the Modrinth App could use to warn users of conflicts. More specifically, the author would select a certain version of some project that's incompatible with a certain version of his own project. This granularity for version specifics is needed because an update to either project could solve the incompatibility and make project-wide claims obsolete.

---

Core logic and edge-cases

If this feature were to be added, it would naturally create three distinctive states an incompatibility relationship could exist in: explicit incompatibility, inherited incompatibility, and solved incompatibility. I'll explain these in depth below. For each state, the Modrinth App should warn the user in different ways when conflicting projects are detected in an instance.
‎

Explicit incompatibility warnings

• When the specific versions of either or both projects that you are trying to run declare they're incompatible together, the Modrinth App would display an overlay warning showing which project declares this conflict, along with optional messages (such as explanations or band-aid fixes) the authors might have configured. This incompatible relationship won't vanish once proceeded, but remain in a new "Issues" tab of the instance.
  ‎

Inherited incompatibility declarations

• In cases where both projects' versions you want to use do not explicitly declare the incompatibility, but either have in the past (and no fix version is available at the time), the Modrinth App will let the user download both projects, but create a warning message at the bottom right and store this potential incompatibility in the issues tab. If an explicit fix version was available, it would simply prompt to update the conflicting projects to the available fix versions. When no fix version was available for this instance, but exists for another modloader and/or MC version, the Modrinth API would deduce that the conflict is present (categorizing it as an explicit incompatibility) and show the overlay warning instead of the bottom right message.
  ‎

Solved incompatibilities

• When either or both of the conflicting projects release a version where the incompatibility has been explicitly declared as fixed, the issues tab will hint this and offer a solution (usually a fix version or downgrade but could support config file patches as well) if there's one that supports this MC and modloader version. If the fix is only available under a different MC version and/or modloader, the issues tab should still indicate it somewhere. The solved state must take priority over the inherited and explicit incompatibility declarations to prevent unwanted logic conflicts. This would fix situations where mod A releases a fix version, but mod B still says that it's incompatible.
  ‎

Now that the core logic is established, I'll go over some essential features that this system includes

• The incompatible projects would be publicly listed under each version of a project.
• When importing/downloading a modpack, the screen shouldn't flood with incompatibility warnings regardless of what the app thinks, since the expectation is that a published modpack will work. The issues tab would still be populated with these conflicts.
• The author should have a say in whether the incompatible content will straight up crash the game, allow the game to launch but have severe disfunctions, or only create some incompatibilities. This would simply add an icon to the issues tab and popups, from which the user can assess the severity of the conflict at a glance. The mildest severity could perhaps suppress overlay warnings.
• A useful side effect that comes along with this system is that people will get warned when they attempt to install incompatible content into a modpack. And because modpacks themselves are "projects" it's like a two-layered system where the modpack author can declare custom incompatibilities.
• Related to this, I think the modpack authors should have a way to configure safeguards for modpacks, preventing explicit and/or inherited incompatibilities from being installed. And while you're at it, have a toggle for restricting individual content types altogether. All being bypassable from the modpack settings or by unlinking the modpack, of course.

I thought last this idea deserved to be here, since it really serves the goal of minimizing the technical difficulties that incompatibilities bring. I know this idea bothers power users, but the benefits of something like this shouldn't outweigh our concerns. Especially when you take into account how this would practically solve the problem where your friends have a habit of installing random mods and just clicking on continue anyway and then bragging to you.

---

Incompatibilities under instances and projects

Up until now, I have only briefly talked about how the incompatibilities would be stored under some issues tab of an instance. But what are these issues exactly, how would they be laid out in the tab, and could projects have a dedicated issues tab for them?

• In all simplicity, the "Issues" tab under an instance would show each project that has incompatibilities in the instance. Not the relationships, only the list of affected projects. This list could be filtered by "Explicit", "Inherited", and "Fixable". You could click a "Solve issue" button (when applicable) to open a dialog to perform the respective actions.
• When clicking a project in the issues list, it would open a screen listing all of the projects on your instance that conflict with this project. This is the default landing page, "Current incompatibilities", but there are more tabs and functionalities in this screen. It's important to note that the incompatibilities in this list could be defined either by this project or the listed projects. This list should show the conflicting projects' icons and names, along with the author-configured conflict descriptions, the severity icons, and the versions of these conflicting projects that cause the issue. The bottom of this page would have the "Solve issue" button, which would perform the same action as earlier.
• You could switch the tab to "All incompatibilities", where you can view all projects (not only the ones in your instance) that conflict with this project, filtered to your modloader and Minecraft version by default. This list could be sorted by whether this project and/or the listed projects declared the incompatibilities.
• This "All incompatibilities" view is essentially the same thing that should be visible as a "Conflicts" tab in any project. The author could add incompatible projects to this conflicts list. Each conflict should include a conflict report that explains the incompatibility(ies) between the projects and lists the affected project versions and explicit culprit project versions. Here, the author could also configure the short description to show when viewing this project under the menus of the issues tab, and the separate warning message to be shown when this project is being installed with incompatible content present.