As you’ve noted, when you use count to choose between zero or one instances of something, you also need to change other references in your configuration, because it’s no longer valid to just unconditionally refer to the resource or module and assume it will always be present.
Even if Terraform offered a third way to decide how many instances of a module to declare, you would still need to update the rest of the configuration to explain to Terraform what should happen in the case where there are no instances of the module.
For example, today you might write something like this, to take a module’s output value if the module is present or null if it isn’t:
one(module.my_module[*].output_value)
It would still be necessarily to write something like this if Terraform had a boolean-shaped enable option, because module.my_module.output_value would fail in the case where it’s not enabled.
Because of this, it doesn’t seem like having a third way to specify how many instances of a module to declare would add enough value to justify the additional language complexity. It’s tempting to focus only on what the count argument might be replaced with, but it seems that your main annoyance is in having to write reference expressions differently, and unfortunately just replacing count with something else would not be sufficient to avoid that, because one way or another you need to deal with the change between something that’s always present and something that may or may not be present.