You can recover the strong form of ML-style FP (albeit without the nice type inference) if you limit inheritance to abstract classes (thus, all classes are sealed/final or abstract), mark all fields as readonly/final, and use interfaces for destructuring (which addresses problems 1,2 and 3 under the “Alternatives” section).
As an aside, one of the big issues with “classical” OOP is that it enjoins the programmer to create phenomena using logic (i.e. wizardry) rather than of using math to model a system (i.e. science and engineering). Among other problems, this leads to designs that break symmetry (e.g. if modeling a bucket brigade, the perspective of many humans passing by a single bucket should be just as valid and available as the “natural” perspective of many buckets passing by a single human). Of course, appeals to symmetry is question begging, and I don’t have time to litigate that here, but it sure seems like symmetry is key to building scalable systems (where scalability means not just number of users, but also things like number of edits to a codebase).
In summary: Classical OOP seems to require that you either have a prior (well-designed and debugged) model against which you can program, or really, really good taste.