As a complement to my other reply to you, I'll note that I developed a simulation system in Java (a very common language), and strove to keep it small, avoid complexity, and generally make it approachable -- but for a long time I remained the only one who understood how the system worked, because you simply had to understand the business domain in order to understand why things worked the way they did.

This is my personal opinion, but I think that domain expertise is a much stronger component of bus factor than language choice is. You can write unmaintainable code in any language. But good code often still has prerequisites to understanding. Meanwhile, if you have the domain expertise, you can get quite far in understanding semi-bad code just by pattern matching on manifestations of your domain.

I mean, that specific library isn't really all that hard to work with. It's not doing anything completely crazy, just somewhat unusual. But in general I think it's probably better to keep the crazy custom environment to personal projects- at least for awful utility macro libraries like mine.

Narrowing down on a single library is one thing. Maybe case by case it's ok. In general if someone showed up and said "I will prototype everything in lisp and you can take it from there" I'd say they are a bit egotistical and not being much of a help to the org. Prototypes are 1% of the work.

And I say this as someone whose full time job was to do research prototypes of robotics libraries for a while.

not only project managers. i love lisp but i dont use it for hobby projects partially because i don’t want to maintain libraries in a small ecosystem where they are often abandoned