That may be true for functions which operate on a generic Monad typeclass, but typeclasses (Higher kinded types) aren't required to implement concrete Functor / Applicative / Monad instances for a particular type, e.g. Maybe:

    fmap f Nothing = Nothing
    fmap f (Just x) = Just (f x)

    pure x = Just x

    Nothing >>= f = Nothing
    Just x >>= f = f x

> things that makes monads notoriously difficult to explain to people outside of the Haskell ecosystem

Huh, I thought a monad is just a monoid in the category of endofunctors, what's the problem?

Some OO languages have a parallel concept in "Metaclass" (https://en.wikipedia.org/wiki/Metaclass) i.e. the class of a class which is structurally similar to "Kind" though of course the mechanics are quite different.

I still have an old book Putting Metaclasses to Work - A New Dimension in Object-Oriented Programming by Forman et.al somewhere.

There is also the classic The Art of the Metaobject Protocol by Kiczales et.al which is quie relevant here - https://en.wikipedia.org/wiki/The_Art_of_the_Metaobject_Prot...

The key difference is that the Type guys do it at compile time (correctness) while the OO guys do it at runtime (flexibility).

The thing that makes monads difficult is laziness and the anti math circle jerk.

You start from a functor which is a data type that admits a map operation.

Then you add of, or pure, to make an applicative functor, and then you add flatmap to make a monad.