Sure. Late binding in Smalltalk-80 means that a bytecode method is selected via a hash table per class and the address of the internalized selector string (atom) as a key. In Oberon, procedures are natively compiled, but each module is dynamically loaded; a module can implement a handler for a message and be separately compiled and loaded by name, so again late binding.
If you're interested in the difference between Smalltalk versions, I recommend Ingall's most recent paper: https://dl.acm.org/doi/10.1145/3386335. In contrast to Smalltalk >= 76, ST-72 had no bytecode, but sent tokens (synchronously) to object instances for parsing (which was called "message passing" by its authors).
> If you are doing whole-system development and have control over the entire thing, then it is that simple
The dispatch mechanism and the described duality is the same, whether whole-system or not.
> Kay's view of OO is a matter of "open world" versus "closed world"
Smalltalk was always a "closed world" (you are always in the same image, but code can be compiled on the fly at runtime), and all calls were synchronous. Since the Oberon compiler and system treats each module as a dynamic loadable entity and supports loading by name, it actually supports the "open world" approach. Interestingly, Kay's view is likely best represented in Erlang, where there are true messages sent asynchronously.
> If you're programming every operation with switch statements that select code paths based on objects' type tags
As mentioned, Oberon traverses the "2D matrix" from the other side. Each module may or may not handle a message in a WITH (i.e. switch by type) statement, but modules per se ar dynamic. So the "a priori knowledge" only applies to the message type.
If you're interested in the difference between Smalltalk versions, I recommend Ingall's most recent paper: https://dl.acm.org/doi/10.1145/3386335. In contrast to Smalltalk >= 76, ST-72 had no bytecode, but sent tokens (synchronously) to object instances for parsing (which was called "message passing" by its authors).
> If you are doing whole-system development and have control over the entire thing, then it is that simple
The dispatch mechanism and the described duality is the same, whether whole-system or not.
> Kay's view of OO is a matter of "open world" versus "closed world"
Smalltalk was always a "closed world" (you are always in the same image, but code can be compiled on the fly at runtime), and all calls were synchronous. Since the Oberon compiler and system treats each module as a dynamic loadable entity and supports loading by name, it actually supports the "open world" approach. Interestingly, Kay's view is likely best represented in Erlang, where there are true messages sent asynchronously.
> If you're programming every operation with switch statements that select code paths based on objects' type tags
As mentioned, Oberon traverses the "2D matrix" from the other side. Each module may or may not handle a message in a WITH (i.e. switch by type) statement, but modules per se ar dynamic. So the "a priori knowledge" only applies to the message type.