No, MAC-then-encrypt is very, very hard to get right, because you have to avoid creating side-channels (including timing side-channels) between the decryption operation, the padding check (if you're using a block cipher mode that requires padding), and the MAC check.

More to the point, if you're fielding a new MAC-then-encrypt design, then I don't trust your crypto, because your crypto knowledge is over a decade old. Krawczyk's paper was published in 2001: https://eprint.iacr.org/2001/045

There are other cryptographers that tend to agree that encrypt-then-mac is optimal.[0]

[0]http://www.thoughtcrime.org/blog/the-cryptographic-doom-prin...

I don't know about the constructions and attack scenarios pertaining to this app, but MAC-then-encrypt is generally insecure; it's not "easier to get wrong", but is itself a flaw (typically: of exposing the cipher to malicious ciphertext, rather than screening it out with a MAC, which is designed to distinguish between valid and invalid ciphertext).

Rogaway's bringing it back with a vengeance though:

http://web.cs.ucdavis.edu/~rogaway/aez/aez.pdf

With AEZ, the "MAC" is actually just a block of zeros.

Rogaway brought it back with a vengeance back in 2006, with SIV: http://web.cs.ucdavis.edu/~rogaway/papers/keywrap.pdf

Essentially all 'misuse resistant' modes are some form of MtE, since in those modes one necessarily needs to process the entire message before beginning encryption. AEZ is MtE in the loosest sense, basically another way to say it's a two-pass/offline mode.

Is there a distinction to be drawn here between "generic composition" and "whatever the term is for the opposite of generic composition"?

Not sure I understand precisely what you're asking. 'Generic composition' is a tricky term, because it tends to hide the assumptions underlying what we're actually composing together. Bellare and Namprempre's paper, which is the most usually cited in this sort of discussion, takes a probabilistic encryption scheme (read: something that takes a random IV) and a MAC, and results in a probabilistic AE scheme. This is obviously not the only way to model encryption and authentication schemes (SIV above transforms those same primitives into a nonce-based AE scheme instead, or DAE with a fixed nonce), but this tends to be overlooked from GC discussions. In some models, MtE and friends is OK. But the truth is that EtM is safe in the widest range of assumptions, while the other ones are more brittle.

That's not MAC-then-encrypt, that's "ECB mode is pretty okay if your message and a nonce fits in your block" plus "let's make an arbitrary-length block cipher". In any case, the result is AEAD, not MAC-then-encrypt.

(That said, AEZ is really interesting.)