Yes, using Monocle for years now. So happy to have rich ecosystem of libraries in Scala land.

I haven't encountered this pattern before. Is there some more information on what problems this is designed to solve?

Does the LSP provide clear autocomplete on what properties can be accessed on the bound _ ?

Asking as someone that doesn't use Scala at all, but has seen the hit-and-miss of some FP language LSPs.

So behind the scenes, every one of those statements will make a whole new user object with a whole new address object so that it remains immutable? And whether that will actually have any real-world performance impact is I guess entirely situational. Still, what happens if you do that with a big object graph?

Also, the original strong need for immutable data in the first place is safety under concurrency and parallelism?

Every scala code base I have worked on, that wasnt written by small team of experts, turned into a huge pile of crap. A small squad of people that treat the language like a religion create an impenetrable masterpiece

Also in F#: https://fsprojects.github.io/FSharpPlus/lens.html

Also available for TypeScript:

https://gcanti.github.io/monocle-ts/

I'm still trying to reason what the value proposition of Scala is in a business sense.

Developer are more expensive and harder to find, the tooling is weaker, the ecosystem less deep, performance suspect, and the overall XP feels clunky.

Plus our hardware is procedural, and contains/manages state within the instruction pipeline.

I strongly believe it doesn't belong as a core business technology.

am I the only one who isn't a little disappointed that this wasn't a library to model the physics of physical lenses?

This has nothing to do with optics, which is a branch of physics that studies the behavior and properties of light.