Recipes can be named the same as the corresponding item. For example in Hardcrafting mod there is an item called "copper-sludge" and also a recipe "copper-sludge".
The mod Crafting Combinator defines virtual signals for each recipe. So that means, that there is a virtual signal called "copper-sludge".
The mlc now mutates a signal, which was related to an item, into a virtual signal referencing the recipe.
Please find save file that shows this:
https://drive.google.com/file/d/18T2J370a4-8BwEuzYdjHN8rpO2qevBd_/view?usp=sharing

Hm, interesting.
This was raised wrt Attach Notes mod earlier, which copies virtual signals to items, but marks the latter as "hidden", so easy to just filter them out.
Guess not so much in this case.

Did write disambiguation code initially for that Attach Notes case, before realizing that there's a much easier fix, so guess will need to re-introduce it here after all.
It does require always typing "virtual=stone" or "item=stone" for all uses for such ambiguous signals, but wonder if it'd be better to change that to some simplier prefix/suffix, like "#stone" for item and "@stone" for virtial signal.

Thanks for report, didn't think other mods doing that kind of thing existed, but guess if it's possible, someone will always do it :)

Re-applied same tweaks in 0.0.66, where basically if you have ambiguous signal name "copper-sludge", then:

• You cannot use unprefixed "copper-sludge" name.

  Should raise Ambiguous short signal name "copper-sludge", matching: #copper-sludge, @copper-sludge error on the combinator. This should happen both if you try accessing name-key in the input tables or end up setting it in the ouputs - all go through same "return signal" func which will raise that error wherever that name can be used to get signal.

• Input tables should only have prefixed name(s) for this signal.

• Inputs/outputs on the right should only show prefixed name(s) for this signal.

• There are no changes wrt all other signals, e.g. "red.stone" or "out.wood" should work fine, but using prefixed names (e.g. red['#stone']) should also work in all cases.

• Disambiguation tables are always rebuilt in on_configuration_changed hook, so if signals change with other mods in the future, it's possible that more signals will require disambiguation.

So basically everything should work exactly same, except if you have mods that introduce ambiguity, in which case you have to use type-prefixes for same-name signals, and will see them as such. Removing such mods later should work with code using prefixes just fine too.
And technically if you want to future-proof combinator code, can always use prefixes everywhere, but maybe that's overkill, if it's just couple recipe signals that happen to get created like that in such mod combinations.

Signal type prefixes are also mentioned at the bottom of the in-game help message, as bumping into them might be a bit confusing.

EDIT: Oh, and it's also a relatively large set of tweaks, so please let me know if anything else changes unexpectedly.
(e.g. prefix popping-up randomly in a gui or table somewhere where it's not strictly needed)

So basically everything should work exactly same

Oh, yeah, except for when someone starts using same prefixes for actual signal names in their mod(s), then it'll get real confusing :)
Which I'm sure will happen eventually, same as with same-name signals here, but hopefully sometime after heat death of the universe.