I like Racket's way of handling them, to a degree. Each of {}, [], and () are interchangeable, and the use of [] is mostly down to convention. For example, it is often used in let bindings:

    (define x
      (let ([a 1]
            [b 2])
          (+ a b)))

By to a degree, I would actually prefer if the convention is enforced.

The convention is enforced in Clojure. [] for bindings, {} for maps.

It is not a convention in Clojure. (), [], {}, #{} represent different data structures.

It's really just syntactic sugar, so I would agree with the statement that the convention is being enforced.

You get different data structures. I.e. printing #{ 1 1 2 2 } prints #{ 1 2 } whereas [ 1 1 2 2 ] prints [ 1 1 2 2].

Not exactly, it uses square brackets for vectors sometimes and curly brackets for maps sometimes, yet other times it uses square brackets for maps:

  (let [a 1 b 2] (+ a b))

Instead of:

  (let {a 1 b 2} (+ a b))

(I think my map notation may be wrong, I always just bounce off Clojure so I'm bound to make mistakes).

I quite like how fennel handles it as well, {} for standard lua tables and [] for arrays, but [] stands to define variables in a let binding. Of course this comes from Lua's quirks, but its a nice, sane way to handle it.

This is an old feature of some Scheme implementations. There are also books where the Scheme code is written this way, IIRC.

Exactly. Totally baffled by the supposed popular reaction to parens. (However I use IDEs that match and color parens so maybe then didn't have such in the olden days referenced here.)

Not having S-expressions is weird. Not being able to drop my cursor anywhere and with a few keystrokes to expand my selection "grab" a referentially transparent value expression and just relocate it or move it or evaluate in the REPL. What are all these other PLs and programmers even doing?

A lot of languages pointlessly make a distinction between a statement and an expression. I can’t imagine why anyone would want that.

It's one of the things I love the most in Rust, and was previously just seen in functional languages.

Even scripting languages like Python feel clunkier than Rust due to the unnecessary statement/expression distinction.