I think it's a pity that SML didn't take over the world, but these days, as an OCaml user, I'd rather see OCaml gain popularity. OCaml now is a lot more advanced and "modern", I think — GADTs, first class modules, etc. and there's a good LSP server, build system, and package manager.
SuccessorML is an ongoing work in progress. It looks to add (among other things) misc syntactic niceties (beginning | in matches, string interpolation, do notation, etc), builtin unicode support, and modular type classes for ad-hoc polymorphism (hopefully somewhat discouraging Haskell's typeclass soup).
We haven't hit the limits of what the language is capable of and a major investment would drastically speed up the process.
I'd say we'll see a Rust-with-GC language fairly soon which will be gravitating towards SML/OCAML with today's syntactic expectations.
You can already pick up Haskell, Swift, OCaml or F# for that purpose, no need for yet another language.
What are your thoughts about Gleam lang? Don't you think it covers those conditions?
It runs on top of Erlang if I see this right which isn't quite what I personally would be looking for (rust or MLTon, OCAML compile to native code).
University Of Copenhagen who previously used SML for introductory programming courses (Now uses F#) have made a package manager for SML modules with MLB files: https://github.com/diku-dk/smlpkg
I like SML both out of nostalgia and for its actual merits, but I don't think that's true. SML was far ahead of its time, but it's showing its age now. Its simplicity is also correlated with an absence of handy features (e.g. ad-hoc polymorphism). Many companies invest in OCaml, which is slightly more crufty but with a (much) more healthy ecosystem, yet it hasn't taken over the world.
I do wonder what would have happened if SML had "won". In many ways it was pragmatically engineered in the early 90s, at a time where no other functional language was comparable (except maybe Caml). Its much-vaunted formal specification does leave a few pragmatics-shaped holes, however. For example, SML has no standardised way of splitting programs into multiple files. Each compiler does their own thing (although at least MLton and MLKit both support MLB files).