Where I ran into trouble was trying to port an app from one Smalltalk to another. Should be easy right because Smalltalk really is a very simple language. But the ways your code could depend on anything in your image are countless. And no standard language definition with conformance tests.

I guess the situation with Smalltalk versions was much like the trouble you have with database vendors today. Or perhaps cloud-providers. Except that Smalltalk was so productive that anybody could easily create their own customizations.

In the database world you can write your own views and stored procedures. But you can't modify the base platform on which you must write those things. In Smalltalk it is very easy to modify the platform, and save those modifications in your image.

IF you had to declare every class and method you use from the image you wouldn't do so much of it. It would not feel very productive having to declare every dependency. But then, you would have fewer dependencies in the end and your code would be much more portable.

Compared to which other 1980's language?

> … smart team working together.

If the team isn't working together the language isn't the problem.

> Where I ran into trouble was trying to port an app from one Smalltalk to another. Should be easy right…

Compared to porting an app between which other 1980's languages?

Say from one C-compiler to another. C is still alive and kicking, Smalltalk not as much as it used to be.

You could write perfectly portable utilities in Smalltalk as long as they didn't rely on any services that were not comparable to what C the language contained within itself.

(Just like "trying to port an app from one Smalltalk to another" would mean trying to port between different Smalltalk gui libraries.)