Whatever you put in the hostaddr field - or any field other than host and port - is one entry. There is no notion of a list of entries in any other field, and no attempt to split any other field on a comma or any other symbol.
[...]
I think the argument is about whether I made the right decision when I scoped the feature, not about whether there's a defect in the implementation.
Implementation comes into play if the scope decision stands.
I have no immediate examples but it doesn't seem that we usually go to great lengths to infer user intent and show hints based upon said inference. But we also don't forbid doing so. So the question of whether we should implement better error messages here seems to be in scope - especially since we do allow for lists in some of the sibling fields.
These are already failing so I'd agree that explicit rejection isn't necessary - the question seems restricted to usability. Though I suppose we need to consider whether there is any problem with the current setup if indeed our intended separator is also an allowable character - i.e., do we want to future-proof the syntax by requiring quotes now?
