You are quite right that the "map part" of flatMap is Functor, as Monads are a model of Functor. IOW, if there exists a Monad for some container, then there also exists a Functor for it.

However, flattening in and of itself does not fully define the flatMap (a.k.a. "bind") part of a Monad. Its atomic use with the map operation is what makes flatMap/bind operations satisfy the expectations of the rules for being a Monad.

Flatten on its own is extremely useful of course. It's often used in definitions of Join type classes.

The rules for Monad are perfectly well-stated in terms of join—perhaps even better stated if you're one to like Category Theoretic diagram chasing.

For completeness, the forms I am aware of are (in no particular order):

* unit and flatMap

* unit and compose

* unit, map, and join

The valid form which you reference being a model of the last one.

AFAIK, for any container 'T' to be able to satisfy the Monad laws, at least one of the aforementioned three combinators must exist for the container.

All three of them must, actually, since if one of them exists, all of them do (and you can define the other two in terms of the one you know.)

What I mean when I say flatMap is tied to collections is in the same sense that I read the poster to whom I was responding when they said it was tied to list, that is, that the intuition that the name "flatMap" leverages is tied to that construct. Obviously, the operation* it describes is more general, but the farther you get from collections, the less useful the intuition that the name leverages is.

(Whether this is better or worse for comprehension than the Haskell style of naming Monads and other related constructs and their associated operations is endlessly debatable and highly subjective.)