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

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).

> 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?

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.