acs-mail, as written today, does not scale. That was the main reason for OF writing acs-mail-lite. It creates all sorts of objects to contain MIME attachments and stuff (I think, I haven't looked at this in a long time) and overall the implementation just seemed very inefficient.
And it was only used in a few places.
While I'm sympathetic to the goal of backwards compatibility, do we really need to keep the worst of the worst available for use forever and forever when we know the code really sucks and is fubar'd beyond any reasonable hope of repair?
How devoted are you to this concept, Tom? If we uncover a security hole that requires an API change to fix, should we leave the hole open because of slavish devotion to the principle of maintaining API compatibility forever?
I wouldn't see any harm in deprecating acs-mail in favor of an acs-mail-lite that has all the features we need but is more efficient as long as we give people ample notice that it's going away. What is ample notice, then? Six months? A year?