I have program
out['signal-1'] = 42

and I connect out to decider combinator and compare signal-1 to 42. I receive false! But I see 42 in decider combinator info...

If I changed signal-1 to water - all works fine

Blueprint
0eNqVk21rwyAQx7/Lwd7Z0Zh0aYV9klGCSa7rsUSDmrJQ/O5TU0q6dU9vhHv6391PPUPdjTgYUg7EGajRyoJ4OYOlVyW76HPTgCCAHPbAQMk+Wi021KJZNbqvSUmnDXgGpFp8B5F59qtA3zWLCu73DFA5coRz/2RMlRr7Gk2QvClkMGgbcrWK+qE+5+XjhsEEYvW0C7ItGWzmeMEgLOWM7qoaj/JEYdRQJA25Y4+OmiqE2yRmY+BAxrros05GKHm+2+5yBhZj3iKwZqAHNHJuAw/gfWql5s5JjMfDYLtciYLFQyaZZiSXzMzvvY/QPm3Nf+J9B0JxhVD+CcJF9S6BL/d3IuPG4LnONGesMpj3vmAp4m66H6RJUwp4DhV6dMP4D82B1NssO0xhulG56mB0X5EKMiAOsrN4B3f2De7sFjdPuMOLS09SLL4AgxMam5DxbVaUO17m603B11vvPwAdYhPc

Can't seem to reproduce the issue here - both combinators work as expected:
http://e.var.nz/2021-02-06.mlc-output-test.mp4

You should be able to see output in Moon Logic Combinator GUI on the right, and input on decider combinator, and that sounds like what you're getting with this setup.

So it seem to be that despite the correct input, decider combinator doesn't work in your case, which might be due to any mods affecting it I guess, and you can check which ones are that by hovering cursor over it, and they should be listed right below the name, if any.
It'd be a weird bug though, as don't think there're many (or any?) that mess with basic combinators like that, which would likely require replacing that combinator prototype with something else entirely.

changed signal-1 to water

Also, don't think there's a "water" signal, if that's what you meant, unless some mod adds it.

I ran into a similar issue where virtual signals I was outputting were not recognised by other entities even though I could see the signal in the UI.

The cause turned out to be another mod - Attach Notes. It creates an 'item' signal for all 'virtual' and 'fluid' prototypes and when MLC iterates over the prototypes in update_signal_types_table() the order is 'virtual' then 'item' then 'fluid' and so the 'virtual' signals end up as 'item' signals.

I was able to resolve by changing the order (in update_signal_types_table) to 'item', 'fluid', 'virtual'.

Oh you're right, thank you for mentioning it.
I even remember having this issue with Attach Notes mod and a different LuaCombinator fork before this one, which is where this "omit the type completely" system was inherited from.

Should probably fix it by checking for duplicate signal names and add a way to disambiguate them in the text form, refusing to guess any ambiguous names within current game-setup, raising a bug there.

refusing to guess any ambiguous names within current game-setup, raising a bug there.

Did implement that at first, but then thought that it'd require typing stuff like "virtual=signal-A" every time when using these two mods together and decided that it's a terrible idea and your original solution with just ignoring these signal copies is probably much better - seems unlikely that they should be used for anything, so why add all this complexity for nothing.

0.0.59 should use that "virtual > fluid > item" order of signals and ignore ones with same name in diff category.
Assuming that mods don't use such conflicting signal names for anything important, it should be fine.

Agreed, I'm pretty sure they are only for internal use by Attach Notes as they are created with all three 'hidden' flags in ItemPrototypeFlags and don't appear anywhere I could find outside of that mod. Let's hope no one creates a mod that copies all the items to virtual signals ;)

they are created with all three 'hidden' flags in ItemPrototypeFlags

Right, why the hell they are even exposed as valid signals here, if they're not shown on any other combinators.
Added game.get_filtered_item_prototypes{{filter='flag', flag='hidden', invert=true}} for items in 0.0.60, which was probably more proper fix in this case, but ordering virtual signals on top of everything else seem to be the right thing to do anyway.