why not allowing dots "." in session name ?

[vaab]

dots "." and ":" are replaced by "_" in session_check_name(..) in session.c.

I get that the idea of this is to avoid ambiguity with grammar in target-session, target-window, target-pane syntax.
But I can't see obvious syntax ambiguity that would be against allowing "." in session name only, as the ":" seems to be required and is the de-facto delimiter of the first part. I didn't find any place where this first part along with it's ":" delimiter is optional.

There are, here and there, minor patches that might be needed on some occasional heuristics that are checking if the whole string has dots or colons. For instance, I came across this in the man page about target-pane syntax: If neither a colon nor period appears, tmux first attempts to use the argument as a pane index.

Why am I questionning this ? It's a real bummer to not be able to name your session with a proper domain-name in the age of sessionizers plugins flourishing everywhere. Most of them sets up everything around the concept of projects and will setup everything around them (these projects are conflated directories with .git inside for instance). The sessions then get: automatically named in a list that can be auto-generated and parsed with fzf-like ways (ordered with zoxide-like ways), then automatically created if not existent, and various helpful setup is made in the session when created (like setting the default dir to our project dir). With a convenient shortcut, this transform usage of tmux and is getting a lot of traction nowadays.

Well, I'd love to be able to do the same thing around domain name of target ssh hosts, and be like being proposed to choose amongst my list of last ssh targets in a fzf-like way, ordered with zoxide like ways, popping out a session pre-logged to one of the numerous hosts I constantly have to log in, in which I'll welcome a distant mosh/ssh tmux session to be auto-created/opened for instance.

I guess, my main question is around : Am I mislead in believing that nothing really strong is preventing us to use dots in session names in the current logic ? And that specific change would not require this much work in the source code nor cause incompatibilities with past scripts/versions.