I would picture something like:

    "depends": [
        { "any-of": [
            { "name": "TextureReplacer"          },
            { "name": "TextureReplacerReplaced"  },
            { "name": "SigmaReplacements-SkyBox" },
            { "name": "DiRT"                     }
        ] }
    ],

The provides functionality is similar, but is only really applicable to situations where the mods are truly interchangeable, e.g. texture packs of different resolutions, or backwards-compatible continuations of mods. When instead the depending mod has implemented support for multiple different mutually incompatible mods (all of the ones listed above have different config formats), attempting to define a usable set of provides identifiers becomes impractical. We would not want to put something like this in TextureReplacer's netkan (with similar entries in the other 3 mods):

    "provides": [
        "TextureReplacer-OR-TextureReplacerReplaced",
        "TextureReplacer-OR-SigmaReplacements-SkyBox",
        "TextureReplacer-OR-DiRT",
        "TextureReplacer-OR-TextureReplacerReplaced-OR-SigmaReplacements-SkyBox",
        "TextureReplacer-OR-TextureReplacerReplaced-OR-DiRT",
        "TextureReplacer-OR-SigmaReplacements-SkyBox-OR-DiRT",
        "TextureReplacer-OR-TextureReplacerReplaced-OR-SigmaReplacements-SkyBox-OR-DiRT"
    ],

Has there been any further consideration for this issue? I think for my mods in question that needed this requirement (as you've mused above) I think I will just list the dependency options as Recommendations for the time being and hopefully the user will choose one from the list. My question is, if the user already has one of the dependencies installed, will it just not list the other suppliers as Recommendations as CKAN will realise they are incompatible with the currently installed dependency?

I'm just trying to think of the best work-around until this issue is resolved.

I think it might list them, but then produce an error when they try to select an incompatible one.

@Poodmund , what is the name of your mod that needs this? I have some prototype code and I would like to run some tests with some (tweaked) real data.

It was basically for any of my skybox mods listed on CKAN... however, the currently listed distribution only has the configs to work with Sigma Replacements for an old version of Sigma Replacements targeted for an older version of KSP.

If you don't mind, I'll polish up the configs required to get the Skybox working with Texture Replacer, Sigma Replacements and DiRT depending on which one is installed, I'll zip it up and then upload it here if you want to test it out...?

EDIT: Just read up on your PR. 😄 Thank you for your efforts with regards to this issue.

Ah cool, now I see PoodsCalmNebulaSkybox, PoodsDeepStarMap, and PoodsMilkyWaySkybox. I think I didn't have the correct game versions marked as compatible when I looked for them earlier. 👍

OK, here's a preview with some local modifications...

$ ~/Downloads/KSP/CKAN/_build/ckan.exe install -c PoodsMilkyWaySkybox/PoodsMilkyWaySkybox-v1.2.0.ckan 
Too many mods provide DiRT OR TextureReplacer OR SigmaReplacements-SkyBox. Please pick from the following:

1) DiRT (KSP DiRT)
2) TextureReplacer (TextureReplacer)
3) TextureReplacerReplaced (TextureReplacerReplaced)
4) SigmaReplacements-SkyBox (Sigma Replacements: SkyBox)
Enter a number between 1 and 4 (To cancel press "c" or "n".): 
1
About to install...

 * Pood's Milky Way Skybox v1.2.0 (cached)
 * KSP DiRT 1.6.1.0 (cached)

Continue? [Y/n] 


Installing mod "PoodsMilkyWaySkybox v1.2.0"
Installing mod "DiRT 1.6.1.0"
Updating registry
Committing filesystem changes
Rescanning GameData
Done!

I have updated the releases of the 3 skybox mods so that they should work in a plug-n-play situation depending on whichever texture replacement mod is chosen/installed.

https://spacedock.info/mod/925/Pood's%20Deep%20Star%20Map%20Skybox
https://spacedock.info/mod/924/Pood%27s%20Calm%20Nebula%20Skybox
https://spacedock.info/mod/926/Pood's%20Milky%20Way%20Skybox

Dependencies:
Module Manager

And one of the following texture replacement mods of your choice:
Sigma Replacements: SkyBox
DiRT (Drop-in Replacement Textures)
TextureReplacer

The new releases should give you a better indication of whether the new CKAN relationship behaviour system is working as the skybox now functions (shows up) correctly no matter which of the 3 texture replacement mods is installed.

EDIT: I think the Sigma Replacements: Skybox version listed on CKAN is outdated though. The new distribution can be found here: https://github.com/Sigma88/Sigma-Replacements/releases/tag/B_v0.4.0

Sigma asked to have all of his mods frozen in KSP-CKAN/NetKAN#6527 and KSP-CKAN/NetKAN#6534. New versions aren't supposed to be indexed.

If thats the case, then the skybox listings will have to drop 'Sigma Replacements: Skybox' support on CKAN and subsequently only list TR and DiRT as the dependent texture replacement mods.

I was also just thinking, this new relationship functionality should help other listings like visual mods that list multiple versions of texture packages at different resolution sizes.

Well, if one of the options isn't available on the game version the user has, it just won't show up in the list. So you can still include it if you care about someone installing your skybox mods on KSP 1.3.1.

For texture packages, those are already handled via the "provides" property. The main mod depends on WhateverTextures, and then WhateverTextures-1024 and WhateverTextures-2048 and WhateverTextures-4096 are all tagged with "provides": [ "WhateverTextures" ] to tell CKAN that they should all be shown as options for that dependency. Sharing code with that feature made it significantly easier to implement any-of.

Ah I see. In that case it's probably better to keep the Sigma Replacements dependency option for backwards compatibility and also if the mods become available in the future.