re engine-specific adjustments to packages, > As for > amsmath, that's still maintained by the AMS, and I believe they're > currently working on an update to that at the moment -- it would be > best to contact them directly. (I'm not sure who the best contact > there would be.) the update is nearing the top of the list, but, sadly, hasn't been scheduled yet, and will surely not be ready for tex live 2011. (the ams have a tech-support address.) that's always the best address to use. i'm usually the person who responds, but mail to this address is archived and it's also available to everyone in the group, so if one of us is in timbuctu, someone else can address problems quickly. in answer to philipp's question i would doubt that the project has the wherewithal to dictate how people should write things. there were fine words spoken, on these lines -- discussing programming style, mostly, at the introduction of latex 2e. those fine words were, by and large, ignored; and back then the only "different" engine we had in play was tex 2.* we also have an aversion to writing things to address engines we have no likelihood of using, or solve problems that aren't likely to come up in any book or journal that we publish. (that's because such things are very difficult to test; we really don't have that kind of resources. i'm simply in awe of the job the tex live gang is able to do along these lines.) that being said, if a report or request comes in with (1) a compelling argument why it is needed, (2) a full example or examples, stated clearly and precisely, and (3) either a code suggestion or a well thought out description of how the change can be accomplished without fouling up anything else, then it is more likely to get looked at with favor. for example, in the course of the update, we intend to look at the package mathtools and a few others that have addressed known problems in amsmath, and also intend to give full credit to the people who solved them. so my rule of thumb would be, fixes _should_ be present in packages or the kernel, as appropriate, but one should accept that occasionally a "tidy-up" package is going to be needed. we're with you, robin. -- bb