We made a blanket call on a half-dozen earlier similar proposals a while back to simply consider the M to be a more generalized suffix, as a majority of the fooM combinators can be generalized in this way.
The alternative duplicates almost all of the APIs and provides no good migration plan. In addition, moving them requires a rather annoying period of code breakage, and fosters situations where users who want to have a wide support window just can't use the new functionality or never realize it is there.
Generalizing them in place, however, grants optimization improvements to existing users.
liftM vs. liftA continues to exist because they actually serve a purpose as a valid default definition for fmap in terms of return and (>>=) or pure and (<*>) respectively.
liftMn vs. liftAn on the other hand, will continue to exist for historical reasons, but we shouldn't seek to emulate that pattern. We may actually eventually switch liftMn to just invoke liftAn if we can show it doesn't introduce any problems, but as this hasn't yet been shown, we're doing nothing there at the moment.
-Edward