Just finished making the mockup for you. This is what it looks like. Top tab is the inventory, middle tab is the skills window from Rereskillable, final tab (and active tab) is the dietary effects window from Diet.

The more diet groups you add, the further the diet window would expand vertically. It's fine if one of these tab windows expands vertically, it still looks and feels great to use the tabs. For example, if Rereskillable is installed, which introduces these tabs, and you're wearing a Quark Oddities backpack, the inventory is expanded vertically, however the tabs remain in the same place, meaning it still looks and feels great to switch between them. You should only expand horizontally as a last resort, or if you think it's the best solution to a certain problem.

My response in the other thread:

The biggest problem with this isn't that I don't think it'd be a good user experience, it's that adding a tab makes it more incompatible with other mods. Imagine a bunch of mods want to add a tab to the inventory, how do they do so without needing to hardcode compatibility with every other mod that tries to do that? It'd be a different case if Forge provided a common API for such a thing, but something like that is not currently present.

Mmm... yeah I can understand why that would be annoying. But is that any different with adding a button? Wouldn't you run into the same issues with inventory buttons? I'd imagine there's a similar amount of mods that add a button to the inventory as there is a tab.

Yeah, I for sure agree that it's definitely an issue that mods would need to be aware of one-another's tabs. Your explanation has definitely made the problems this system would bring more clear. My main curiosity though was whether there even is many mods currently available that add tabs to the inventory, especially enough to completely dismantle the additional compatibility an offset configuration would give you. Like for a standard sized inventory that would have to be what, 5, 6 tabs? Plus don't forget, there's also the other side of the inventory, giving you a further 5-6 tabs.

Edit: Ignore this paragraph, it slipped my mind that each mods actual tab screen would need to be aware of the tabs from the other mods that add tabs to display all the tabs on each screen correctly.
Speaking of offset configuration, if offset configuration existed in each mod that added a tab, although limited like you mentioned, this would remove the need for mods to be aware of one-another (although not the best solution, because default compatibility is ideal).

I feel it's a matter of deciding whether the extra comfortability to user experience and more refined design is worth the lack of future-proof mod compatibility: a pros and cons situation.

Regardless, I can't stress enough that I support whatever decisions you decide to make, because they honestly all end up being great decisions in the end. I'm just trying to possibly provide some help in making the mod the best it can be. As from previous experience giving feedback to several of your mods, I know you're a great developer when it comes to responding to feedback, and responding to problems extremely quickly.

I feel it's a matter of deciding whether the extra comfortability to user experience and more refined design is worth the lack of future-proof mod compatibility: a pros and cons situation.

This is definitely the crux of the issue and I currently feel that the former is not enough to justify the latter. Even if there are only a tiny handful of mods that even add tabs like this currently, if I add more precedent to this concept then there may be more mods that crop up that do this. And for each one that shows up I'll need to update this one. In addition, I haven't even gone through the issue of how all of these mods would need to form an unspoken consensus about how the tabs are ordered. It's basically a huge bag of worms that I don't want to open or participate in at the moment.

Regardless, I can't stress enough that I support whatever decisions you decide to make, because they honestly all end up being great decisions in the end. I'm just trying to possibly provide some help in making the mod the best it can be. As from previous experience giving feedback to several of your mods, I know you're a great developer when it comes to responding to feedback, and responding to problems extremely quickly.

Thanks, and I hope you don't take any of this as a slight against your idea. There are certainly benefits and even just the discussion itself is meaningful. I welcome any and all feedback that people provide as I know it's coming with the intention of trying to make the mod better.

For now, I'm deciding against the idea of a tab so I'm closing this issue. But if something changes, maybe a new API comes out or Forge has a new feature that makes this easier or anything else that might change my mind about the situation, feel free to speak up about this idea again in the future and I'll revisit it.

Sounds good, and I agree with you, you've made several good arguments to why this idea wouldn't be the best as of now. I might consider suggesting to the Forge team that they integrate a feature like this into their API, but I think it's unlikely that any action will come from it. I don't think the Forge team are nearly as responsive to feedback of this nature as yourself or a select few other developers. Besides, if I really want the feature I can always create a personal fork of this that contains it. Thanks for the detailed conversation about this, I really appreciate it.

It's similar, but there's a reason why my two mods that add to the GUI (Curios and Diet) have a client config to configure the offsets for the button. Users and modpack developers can just move the buttons appropriately if something else is in the way. You could argue that I could add offset configurations to a tab as well, but this is inherently more limited because it can only be adjusted vertically and will eventually run out of space given enough mods whereas a button can really go anywhere.

Moreover, there's a subtle but important technical overhead:

If you have a button that leads to another screen, then all you need is another button on that screen that takes you back to the inventory screen. The implementing mod doesn't need to know about any of the other buttons on the inventory screen.

If you have a tab that leads to another screen, that screen must then have every tab on it as well. The implementing mod is then required to have knowledge of every other tab that could possibly be on the inventory screen. Otherwise, the tabs would disappear and it would basically negate the advantage of this system. This is a large maintenance burden.

As a more concrete example: If I incorporate this tab, Diet must have knowledge about Rereskillable's tab in order to draw it on Diet's screen. Similarly, Rereskillable must have knowledge about Diet's tab in order to draw it on their screen. This adds an additional maintenance burden to both of us. Meanwhile, in the current situation, no one needs to know about the Diet button except for Diet itself and the user.

This is why it's important that this implementation come from a common API like Forge instead of any single mod. The most similar example of this is how Forge and Fabric manage the creation and rendering of additional Creative tabs from mods.