What is the new feature or improvement?

This might be a bit hard to explain, but basically there are many mods (or datapacks especially) which include some sort of feature dependent on having an item inside your inventory. Whether that would be a compass to give a HUD for in game time, or a compass for coordinates, or even cases like a map hud or similar.

From my experiences, many of these mods won't work with curios slots unless they are developed such to check the curios slots.

My suggestion, if it is even possible / if i'm understanding curios' functionality correctly, is to have the slots added by curios to be viewed by minecraft as part of the player's base inventory, and not a separate inventory. Possibly this could be included as a toggle in settings, if it's even something that can be done in the first place.

That way, if a mod or datapack has something that detects items in the player's inventory, it'll also check the curios inventory without needing support on that developer's side.

Now this might seem weird to suggest considering that the only benefit this gives is for curios slots, meaning the item in question would have to already support a curios slot. But my reasoning is so players who might want to add items to a curios slot independent from one of the aforementioned mods can do so without needing the direct support by the modmaker.

Prime example, the "Info Tools" datapack/mod here (https://modrinth.com/datapack/info-tools). It's developed as a datapack using that formatting, and checks to see if a compass or clock is in your inventory for the mod to work.

Right now if you have either item inside a curios slot that supports compasses or clocks (i.e. a second datapack made independently), the info tools features will not work. So with the suggestion here, without anything extra needed, the feature would then work without needing to request that support by the modmaker (who might not have experience in implementing curios functionality on their end, esp if it's a datapack).

Again, this is all with the assumption that this is possible to include, but it very well might not be. Either way, hope you may consider.

This is a bit of a tricky topic.

The requirement of specifying integration with Curios in order to activate certain functions is certainly one of the most prominent gaps in functionality, since, as you mentioned, many developers or datapacks simply do not account for Curios for a variety of reasons. The problem is there's no magical solution for it, as it's a confluence of multiple routes and interpretations of what exactly an item in a curios slot represents.

I think it's rather easy to implement something that can accomplish this on some level, notably in regards to features that only want to know if something is in the player's inventory or not. I don't think anyone would consider Curios, conceptually, as a wholly separate inventory, so I could inject the required logic into entity NBT predicates and player.inventory.contains calls to cover some datapack and mod usages. This is something I'll be testing in future updates.

However, many mods don't actually use that sort of logic because they are also interested in where the stack is and what the stack is. Both of these are tricky to do without interfacing with Curios because there is a distinction between curios and the rest of the inventory, the same as there is between armor, main inventory items, and offhand items. If a mod tries to access these vanilla compartments, Curios cannot automatically infer whether it should be included because Curios can act as any of these depending on what the modder is using them for. Some modders might be using them for armor/equipables, while others may be using them as inventory extensions, and it could be an issue if they suddenly grab Curios in a context they're not expecting. For instance, modders may try and query the armor list and the items list, which represent two compartments, but Curios would erroneously count an item twice if it tries to include itself in both compartments.

Even if we ignore that particular issue, there are technical issues with the idea because it involves really invasive changes to the vanilla inventory code that could be error-prone due to changing the underlying assumptions modders may have about the inventory, its structure, and its contents (particularly because Curios has a dynamic inventory size).

This is all to say that it's something I'm very interested in making better, in particular the ways I outlined in paragraph 2, but I don't think it's feasible to try and cover even most of the use-cases involved in this simply because of the conceptual and practical obstacles. That said, I'm of course open to any ideas or thoughts from other developers who may believe otherwise.