i just feel like it would make sense to provide the "sodium" mod id as well as the already provided "rubidium" mod id

This is intentionally not done, for a couple reasons. Ideally I wouldn't provide any other mod IDs except Embeddium, but most Forge mods that interact with Sodium internals already expect and use the rubidium mod ID, so I provide it for backwards compatibility.

Providing sodium on the other hand is not really necessary from my viewpoint, again because Forge mods deal with Rubidium, not Sodium. I think the outcome of this in practice will be players attempting to use addons for the Fabric version of Sodium on Forge via Connector, which is a very risky idea (because Embeddium is not identical to Sodium), and is not something I'm currently aiming to support. I don't want to make that easier by allowing the addons to silently work instead of requiring the player to go through the trouble of writing a dependency override.

Happy to be talked into it if you see something I missed. :)

So the issue is that depending on how invasive those mixins are, they won't necessarily work on Embeddium as-is, as sometimes a method signature might be changed to pass extra context, or I might call a Forge-added method in place of a vanilla one.

Usually my preference here when dealing with a Forge mod would be to add an API that does what they need, but that won't help you if you also want to be compatible with upstream Sodium.

@embeddedt
some fabric mods have mixin plugins that check for sodium, and they load separate mixins for sodium for compatibility
ex: Wilder Wild
so using them with Sinytra Connector causes a crash when used with embeddium because it thinks sodium doesnt exist