>I'm familiar and reasonably comfortable with the "image" concept from Lisp,

I'm primarily a Schemer, so correct me if I'm wrong, but lisp, at least since the death of the lisp machine, doesn't have an image: it has a live environment in RAM, and there's no easy way to dump that to disk. It's just a REPL.

>I have to believe that there's some way to remove the development environment from the final image, but I didn't find a way to do that with Squeak when I tried it

You certainly can, presumably just by stripping them out, but I'm not 100% sure, as I've never tried. MIT did it though, back in the days of squeak 2.X, leading to MIT Squeak, which is Squeak stripped down to just the bare necessities to develop Scratch. They didn't remove the class browser, workspace, transcript, or debugger, but I imagine it wouldn't be too hard, and besides, if there was a problem with your code in production, you'd want them there.

>There's also a question of how well the environment within the image can communicate and interact with the host environment -- from the end user's point of view, it looks and behaves differently from everything else they use; how is it for the programmer?

Squeak's got an FFI, and has binding for network access, etc., but one of smalltalk's greatest failings is its inability to play well with others. Scratch 1.X is probably the best example of a Smalltalk UI in action that you'll see, and you can see how foreign that looks.

>The biggest problem with the image-based development style is reproducible builds. If your application has been created by incrementally tweaking a live environment here and there, how do you make that reproducible? How can you then save all the necessary code and data to recreate that state from a fresh image?

And this is where the misunderstanding stems from: The image is a live environment, yes, but it is also your entire application, and your source code: When you hit 'save' in a smalltalk image, all of your code, as well as a snapshot of the state of every single object in the system, is saved to disk. There is no file to forget to add things to. If you added it live, it's in your system, same as if you'd typed it into a text file in lisp.

>Along the same lines, how would you work with source control? Checking an image into git doesn't seem like an ideal solution.

It's not. Which is why Smalltalk has its own version control system, and (I believe), a git bridge, allowing you to save only your classes, your projects, and what you've changed to a repo, and download them to other images.

>In regard to code organization: files let developers organize the code however they feel is best, not the way some browser author decided is best.

You're still thinking in terms of files: In a smalltalk vm, the browser isn't organizing files: it's organizing classes. And you can sort those classes into packages, and the methods into protocols. Not perfect, but pretty good.

>Furthermore, a good text editor can help with navigating, exploring, querying, and processing text as well. Text editors aren't somehow limited to only enabling writing -- they have features to assist in reading and comprehending text, too.

An ST environment can query, navigate, and explore the objects that text represents, and tell you far more about what your code is doing that any text editor.