I agree with @lucatrv that the Mesa notation is very clear. I also don’t see any fundamental reason why parsers should not be able to handle unbalanced brackets (i.e. things like [0..100) or (0..1]f64, or more generally (EXPR].) — that said, many syntax highlighters are likely to trip up on this without fixes.
… but, is this enough? For example, given the ways brackets are currently interpreted, why would (a..b) not be interpreted as a..b and [x..y] as an array? Matching the .. inside might help with this (like (1,) is interpreted as a tuple), but complicates the parser.
And: (a..b) is currently legal syntax (for a..b). [a..b] is also legal (an array of length 1 containing a range). This proposal would change the meanings.
Using a unique separator (maybe ::) instead of .. would help work around the above issues, but is still not nice (though as long as the un-bracketed a::b is invalid syntax, it is no worse than the current tuple syntax).
TLDR: supporting [a..b) or probably [a:b) would break too much, while [a::b) might be feasible.