Henrik,
And now hopefully we can get back to the issue I was intending to discuss with my posting.
Since nobody has commented on your original issue, I'll give it a try. I need to say that as much as I agree with your general principles, as much I must disagree with your concrete interpretation. In particular the first principle saying
(1) Architectural law: Modules may only depend on (use code in) modules "further in"/closer to the core. (Outward dependencies are forbidden.<*>
is a very good general principle but your interpretation of it in
(*) This means no more "String asUrl", because this makes the core module with String depend on the much less vital module PWS or whatever, so you have to load PWS to use strings.
is just utterly wrong. You could equally well declare that there must be none of the "isXYZ" methods in Object. That effectively leads to the style of using "((x isKindOf: Foo) or:[x isKindOf: Bar])" and that's most certainly not the right way of dealing with the issue, is it?! So...
_Maybe_ we need to allow outer layers to add code in inner-layer-classes, but this creates spurious sideways interactions between modules.
... my feeling is that the above should not read _maybe_ but _absolutely_. Please note that there are no spurios interactions between modules as long as long as methods are added and not modified and that adding methods can be done in a perfectly safe way if selector name spaces are supported. In this case PWS would - by using #asUrl - make itself a dependent of the URL module (making #asUrl and the URL classes part of PWS itself defeats your own interpretation of a layered architecture) the URL module would (by implementing a method in String) be a dependent of the String (or Core) module and everything follows nicely your general principle.
Similar things can be said about some other concrete interpretations you are giving. Two examples are
There is no longer any sharp line for what goes "into" Squeak here. This is very different from today's either-or-image situation.
... and ...
There would need to be separate update streams for each module (and updating mechanisms would need to be provided by the system as well).
Neither do your general principles imply that there is no longer going to be a sharp line nor do they imply separate update streams. Whether or not there is a sharp lines depends on the distribution and inclusion mechanisms used (meaning that there could very well be an extremely sharp line for various things - just take the SWT image and check it out; a very sharp line can be seen here cutting off every last bit of media related stuff in favour of other things [this is no complaint, just an observation]) and the updates could still come out of one source - all that is required is a dispatch mechanism and whether this mechanism is on the client or the server side is a completely independent issue.
So, I do agree with you on the terms of the general principles. But I can hardly agree with your interpretaton in the concrete context.
Cheers, - Andreas