if JS tried not only to use Lisp-like semantics but also Lisp-like syntax then probably we'd still be using it untyped

This. I can't count HOW MANY FUCKING TIMES I had to either look up the source code or search GitHub for code using a function from a given library because the documentation was so laconic and/or disjointed.

does it federate? 🦊

Clojure. Although it's currently the most popular lisp but the ecosystem is not super lively and sometimes you need to rely on Java interop. This also severely limits the platform flexibility, if more things were written in pure Clojure or targeting BEAM or CLR it'd be nice. But luckily at least unless a library you use doesn't rely on Java interop, the language is designed in a way that really reduces the bit rot.

Fun thing about it is that despite the S-expressions which you love to appreciate - I mean, it usually looks better than }) at the end of a Promise / closure in js or super deep nesting which you'd easily resolve using a thread last macro in Clojure. Therefore I'm also really excited that the pipe operator is finally coming to JS soon. Just add colored delimiters to your IDE. The virtual lack of syntax makes it quite easy to pick up.

With lisp semantics and minimal syntax that resemble the lambda calculus very closely, dynamic typing is rarely an issue (you can still specify types optionally), not to mention that pure functions are super easy to reliably test. Also, many things like DOM, nested data structures, b-trees (to a degree) or ASTs are actually structured like an S-expression tree, making Clojure good for such applications. All of this allows for clean code that does not feel like an assortment of free functions but is usually very loosely coupled yet everything seems to fit really neatly together like a coherent tree.
In general LISPs, as the name implies, are a superb tool for studying algorithms and DS in a way that allows you to focus on the problem itself more than the implementation, unlike in imperative languages where going into every little step in what feels like almost operating at individual CPU instructions at times can feel overwhelming and confuse the hell out of you.

Realizing the open-closed principle with Clojure comes pretty naturally since you'd more likely use function composition or write new transformations than modify the existing functionality.
Since functions are the primary unit of abstraction, dependency inversion is also trivial to adhere to.
Also protocols, which are somewhat more powerful than interfaces in some OO languages. They offer multi-method dynamic dispatch, retroactive polymorphism (extending types defined outside the current codebase), are independent from class hierarchy and are generally somewhat more succinct as virtually everything in that language.

First-class support for STM and immutability also make it good for concurrency like most functional PLs and make it a bit more intuitive than the actor model of Elixir/Akka.
Some Clojure frameworks do as well in certain benchmarks as those written in Rust.
Also compared to some other lisp dialects, the "primary" data structure is not a singly-linked list.

It's goto data representation format, EDN is also a really nice thing.
And you have a REPL and get to choose what should be compiled AOT and what JIT. It's most popular build tool, Leiningen is quite neat and in my experience has been a little bit faster in terms of dependency retrieval than Mix used by Elixir.

It can also transpile to js or dart. It generally is a quite flexible and extensible language where the said extensibility does not really make you feel the levels of inconsistency comparable only with PHP a couple years ago before they've decided to get it's shit together as much as possible as can be the case with Haskell codebases that rely on a large number of language extensions.

And lastly, first-class documentation support but that should be a standard (looking at you JS and everything that still uses Doxygen)

Tbh Clojure's greatest Achilles' foot is the baggage of JVM with it's lengthy stack traces, startup time, lack of tail call optimization, different paradigm and backwards compatibility issues. So if the question was which runtime you wish was more popular, I'd pick BEAM. But in it's current state, whilst BEAM is more suited for functional programming, Clojerl doesn't allow you to do much more than the standard library since many libraries wrap java, like web frameworks for example.
But on the other hand, JVM integration might make it easier for teams using Java or Scala to adopt Clojure.

Also it might not do the best job of handling bugs gracefully. This is good in the sense of giving you those almost Rust-like levels of strictness but without the lengthy compilation time but if you are looking for a way to move fast and tolerate some breakage, Elixir could be a better pick.
Also currying is not automatic and you have to use partial or macros.
But speaking of macros, they are almost as neat as in Rust and much more intuitive than in C or Scala.

Luckily LineageOS and GrapheneOS have a lockdown mode (Graphene also supports disabling fingerprint for screen unlock), though rebooting your phone usually doesn't cause you to lose any work since everything autosaves as phones kill background apps to save battery and memory. Separate user profiles for situations like protests or certain contexts (preferably with some dummy data to make it not look to sus) are also useful.

you made me nostalgic for the floppy tray check sound from my old PC ;;

Play undefined, win undefined

And your IDE is laggy as hell

getting into power in corporate env usually takes fairly strong narcissistic traits so no wonder such control freaks will try to abuse their power to micromanage the "human resources"

non-AMOLED devices spreading misinfo by enabling dark mode by default on low battery and it's consequences...

lmao

If I had a dollar for every time proprietary software users act surprised when it abuses them...