After the previous post, I intermittently worked on sml_tk. In particular, as mentioned I wrote a usable .smackspec and .use files for package management and build system respectiely. Of interest is that I wrote the .use file to only expose core Tk functionality and not any of the test code or SML extensions.
In the end, the software seems eminently suitable for vanilla GUI tasks. However, I set myself the goal of something more unusual, I wanted to multiplex socket I/O with the GUI event loop. This turned out to be problematic.
In pure Tcl, the accepted solution is to turn file I/O into just another event in the event loop using the fileevent feature. However this works with Tcl channels, not UNIX fds or anything usable from SML. Also, it won't work on Windows. So I decided it isn't feasible. My second choice, to run GUI code in one OS thread and socket I/O in another, seems like it should work. However, I consistently got crashes which led me to believe that some part of the software stack is not thread-safe.
Edit: I've since found the Giraffe library which supports writing Gtk-3.0 GUIs that work in multi-thread apps.
I wrote basically the same test case in SBCL & LTk and there were no problems, so I have fallen back to that for now. It's not my first choice, but if I do have to write a lot of algorithmic code I can maybe use Shen there.
It turns out there's no substitute for writing code. It's a shame that compile-time type-checking of Tk interfaces isn't there yet, but run-time is ok. Lisp wasn't my first choice, but I have to acknowledge that it's the best for delivering desktop software. I'm still not a massive fan but my lack of enthusiasm may have a silver lining in that I'll use the language as a mere tool and maybe write more straightforward code, like Python used to be.
I think I'd still like to use SML with a more restricted stack, like in server code.