Ok, did not realize you were the author, apologies.

I think we're talking about different things so let me be clear about what I mean.

By isomorphism I mean a loose equivalence where the only thing that needs to be equal is structure. AN isomorphism between two different things is the preservation of Structure. In this specific case the structure I'm referring to is:

  a system consisting of many (nodes that hold state and specific methods for communicating) that are talking with one another. 

This is what I consider to be the modern definition of OOP and is isomorphic to Alan Kays definition of message passing between objects(nodes) that hold state.

Anything that is isomorphic to the structure above is isomorphic to each other.

So using "=" to refer to an isomorphism what I was referring to is that:

JAVA = smalltalk = Servers communicating via REST = SERVERS communicating via SOAP/CORBA = objects and messages = OOP = nodes holding (state and methods) and communicating with one another.

So because all these things have an isomorphism they all have the same "Structural" problems as OOP that I described above and they are all basically different aspects of the same thing.

I think what you mean by "REST" worked and "CORBA" didn't is that CORBA/Soap didn't become popular while REST/WWW did, but if you look deeper there is no difference between the two concepts. CORBA/Soap is isomorphic to OOP which is isomorphic to REST. All these things are built off of a model where "nodes with state and methods communicate with one another" Maybe one system became popular because the semantics were easier to grasp or maybe there was a lot of extra fluff that needed to be implemented to get things to work. Either way I am not referring to this surface level difference. I am talking about a deeper OOP problem.

I am referring to an innate structural problem that comes with nodes that have both methods and state. The unionization of these two things leads to a design flaw.

Imagine one node with state that has a method that needs to be used in the context of another state. For example I have a node called SortedListOfCarsByPrice that contains a sort method. Later on, (possibly years later where design requirements change), in the design I realize I need an additional object called SortListOfPeopleByAge object. The design problem I hit here is that I want to reuse the sort method but it is tied state of SortedListOfCarsByPrice . The method modifies the state of the SortedListOfCarsByPrice object so I cannot pull it out and reuse it in another object that needs to modify the internal state of SortedListOfPeopleByAge. This is a trivial example of something that happens all the time with OOP and anything that is isomorphic to OOP.

Of course I could of had Parent Object with that method and had SortedListOfCarsByPrice and SortedListOfPeopleByAge be children of it, but my argument is saying that because the process of design makes it so that we may not know about this connection in the beginning. We usually come to realize this flaw later on in the game where it is essentially too late to change. OOP hits all kinds of design problems like this AS does microservices because the concepts are Isomorphic.

So to solve this problem Functions and state need to be subdivided into a different structure: The following definition is not isomorphic to OOP:

   A system where there are two entities: Functions and Data. Functions only take input data and output new data. Data is an immutable unchanging piece of information that contains no methods. 

By splitting Objects into its constituent pieces suddenly no sort method is ever tied to the data of SortedListOfCarsByPrice. By it's very nature the sort method is tied to nothing and can be moved across the context of all sorts of data. I can use sort to sort lists of cars by price and People by age because sort is not tied to data.

If you understood what I said above maybe that will help my original thesis above be more clear as it certainly looks like I have failed to communicate my main point.