Will try to give answer to 2nd and then 1st of the questions, since 2nd's answer opens up 1st's.
Back to basics: MAC is Message Authentication Code, which gets attached to the message and provides authentication of the message upon receipt. Authentication here means:
- Detection of any change made to the original message either by error in transmission or tampering by an attacker.
- Detection of a completely forged message by an attacker.
This all means we have to generate the MAC value from the whole message being sent. When the message is cipher text, then to protect the message MAC should be generated from the cipher text, and all of it as it is in the message, which means any IV and what not included.
If we are sending a message which contains cipher text and other data which are plain text, then we need to MAC the whole message again. Because again MAC is to protect the whole message.
Question then: does this protection of the message also mean protection of the plain text? Yes it does, because there is one to one relationship between cipher text and plain text. If cipher is good so is plain text.
I read some references against this saying if by mistake a different key was used to decrypt the cipher text, we won't be able to detect this when Encrypt-then-MAC is used. But protection against wrong key usage is wrong expectation from MAC. MAC is supposed to provide detection of errors or tampering of the message, not provide mechanism of detection of wrong key usage during decryption. MAC usage doesn't even know if encryption is used or not, it protects the message.
If an application is prone to using wrong keys, then correct thing to do is to prevent it from doing so. And one way this can be accomplished by is, including a key identifier in the message, so that receiver will know exactly what key to use. If this is done, the message will now be cipher plus the key identifier. The MAC will be generated from these, since that is the message now. And that means any tampering of the value of the key identifier will be detected too.
If instead MAC-then-Encrypt is used, there is no way to authenticate the message, since message itself won't have a MAC attached to it. That opens up attack surfaces like "Padding Oracle Attack", which relies on receiver not being able to detect forged or tampered messages, due to lack of MAC in the message.
With Encrypt-then-MAC, actually more accurately to call it "Always MAC protect the whole message" case, receiver will detect tampering or forged message immediately without doing any more processing. It is safer!
Now to 1st question, the above answer by given by Seth is a good one. My only addition to it would be why would you want to do that anyway? In one of the comments the explanation to why was given as:
"..My reasoning is when I have something like HMAC(some || concatenaed || fields || ciphertext), it might be possible for an attacker to shift the boundary between "fields" and the ciphertext, because ciphertexts usually don't have a fixed length...."
Reminder again, you need to HMAC your whole message and as is!, so that you are protecting your whole message as is. In other terms what you pass into HMAC has to be the whole message and as is. The receiver will have to do the same for validation.
If your message structure is open to shifting boundaries between parts of them, then you have problem with your message structure. Solution to that will not come from using additional SHA call. Solution to that would be changing your message structure and format not to allow such boundary shifting; such as including length specifiers for variable length parts, separators etc.
Then since you have to HMAC your whole message as is, those length specifiers, seperators and etc will be included as part of the value that is passed to the HMAC function. Which means you won't have boundary shifting problems to worry about there, as long as your message itself is fine in that regard. If not, you have a problem to solve before coming to HMAC call.
Hope this helps.