Sorry to contradict Tom here, but I'm not talking about breaking existing code. If the OCT wants to move my initial proposal of upgrade of acs-mail-lite to a overhaul of the mailsystem, that is up to them. I merely propose to use the contrib version of acs-mail-lite instead of the version that resides in packages, as the contrib version contains quite some *enhancements* that are *not* breaking any existing code.
So maybe we should stick with the *original* TIP and make a decision on this before we talk about changing the whole mailsystem. But again, this is up to the OCT.
One note on the API changes. If I'm not mistaken, mutation is welcome in the world of science, otherwise progress would not happen. What we just have to make sure is that the API does not break existing code (thereby not taking a darwinistic point of view). Which is really easy to accomplish, especially in this case.
Anyway, all I can do is to mention that there is acs-mail-lite in contrib, that does not break existing code, is compatible to the version in packages and it's up to the OCT to come to a decision whether to use it for OpenACS or not. Anyone wanting to get bouncing and documentation can still take the contrib version after all.
