The issue with the Filter is a good point. At the same time, if two LoggerContext's are sharing the same configuration you would end up two buffers each containing only some of the events. This can occur if you have a parent and a child ClassLoader (such as in Tomcat) and the Log4j jars are in Tomcat's directories, not the web apps. In that case, when an error occurs you would get an email but it would be missing either all the log entries from classes in Tomcat's ClassLoader or all the log entries from the web app ClassLoader. With a single manager they are all combined and you would get what I think is the expected behavior.
A similar problem occurs in the RollingFileAppender. In that case, once the manager has been created for a single file subsequent appenders will use it and whatever they specify for a policy or strategy will be ignored (to do otherwise would cause quite a mess).
In this case I would think the String value of the Filter, along with many of the Appender parameters, would become part of the manager's "name". Since it will be pretty long I'd probably use an MD5 like the Flume Embedded Appender does.