The "or" is quite important. It is not just a union datatype. Either[A, B] = Left[A, B] + Right[A,B]. In the case when M is Set it allows to build a Set whose members are Left[E] or Right[SetTree[E]]. This is more general than Set[E] + Set[Set[E]] + ...

In the case when M is a simpler monad like Option/Maybe you are right that you just get a chain of Some/Just wrappers of arbitrary length, and that's not very interesting, but it is a monad. I haven't worked out an intuition of what this means if M is the State monad.

Yes, you are right about the Either definition. I will correct it. I am not quite sure what is indicated by the "+" in your formulas. What would simply  A+B mean? (I am not proficient in Haskell, I use Java and Scala only).

As an example of a ListTree, (using for List and L for Left, R for RIght)

I don't see how that fits with the pattern M(T+ M(T+ ...,T+...))

I have been exploring the StateTree monad that is generated by this recursion.

Because there is no multiplicity at each level (as there is in Set or List), then in each case an instance has a type of

State[S, Left[A]] or State[S, Right[State[S, Left[A]]]] or ...

The StateTree would have a run(s) method that produces the same result as if all these state transitions had been squashed into one using repeated binds.

The squashing operation is what I call flatten - it is defined for every M-tree.

The difference between a StateTree and a State obtained by flattening the StateTree is that the individual steps are still accessible, so if I like, I can step through the state transitions one-by-one, examining the intermediate state, and also seeing the outputs at intermediate stages, which are just thrown away when the StateTree is flattened.  I can even choose to modify the state manually at some intermediate stage. So if we think of State as a program for a state machine, then StateTree is a debuggable version of that program.

I looked up the definition of coproduct - it is disjoint union. The problem I found is that, depending on what the base type is, the union is not necessarily disjoint, and so the Left and Right markers are necessary for keeping track. For example, if we have SetTree[SetTree[A]], which we have to deal with for defining join, then if I don't have the Left and Right markers in there, I don't know if I'm dealing with a leaf of the top level tree that happens to contain a tree, or a branch of the top-level tree. And if I can't tell the difference, then the join cannot be defined in a way that satisfies the monad laws. (At least I couldn't do it.)

Thanks for the explanation of disjoint union - that is helpful. I am relatively new to both category theory and functional programming, and trying to increase my proficiency in both by working through such examples as they arise in my work. So I am happy with both methods of describing, but it may take me some searching and questioning to actually understand them.

Based on what I understand of monads, I would argue that M(M(T)) is not the same as M(T). Each monad is required to have a join transformation join: M(M(T)) -> M(T) that is in some sense the inverse of the unit transformation unit:T -> M(T). So this collapsing of nested monads does not occur automatically, but has to be done by applying the join transformation.

I don't see the isomorphism. Take lists, for example. There are several instances of List[List[Integer]] that map to the same List[Integer] when the join transformation is applied. E.g.  < 1, < 2, 3> > and < , >.

Correspondingly with the unit transformation. What you get from applying the unit transforamtion is lists of length 1, leaving out a lot of instances of type List.

So when you say isomorphism, you can't mean a 1-1 mapping as defined by these transformations.

L(X) -> L(L(X)) is a function signature. There a lot of different functions that satisfy this signature. Some of them can be created by applying the functor to a function of type X-> L(X). That would be the case for f = L(unit). In the case of L=List, then f([1, 2, 3]) = [[1], [2], [3]]. True. But there are lots of other functions of type L(X)->L(L(X)). Here's one

g([1, 2, 3]) = [[1]]. g takes a List[A] and makes a List[List[A]] from the first element only, or the empty list if there is no first element.  If L is ListTree, then there are similarly a bunch of functions of type ListTree(X) -> ListTree(ListTree(X)). Consider this one: take all the leaves fo the ListTree that are at the, say, second level down from the top, collect them, in order, in a List, cast that to a ListTree of depth zero (i.e. all leaves are at the top level) and then wrap that in another ListTree.

I'm not seeing how a function such as this (which explicitly makes use of the ListTree structure, as in depth) can be compared  to the functions of type List(X) -> LIst(List(X)).

Not sure where you are really going with this. The whole point of creating these structures in the first place was to capture things which are NOT possible with the original monad. Ordered finite trees (ListTrees) are a richer category than Lists. Why would we want to prove otherwise?