Sorry, Scott, I don't understand your comment.
Orchestra provides a FacesContextFactory that returns an anonymous class that subclasses a base class FacesContextWrapper. This is all standard decorator behaviour.
But the orchestra FacesContextWrapper was declared package-scoped, as it isn't a class that we want other people using; it's just a base for the FacesContext instance that we return. Orchestra doesn't add any new methods to the FacesContext class.
It is the new tomahawk code that is using reflection to try to handle methods added by JSF1.2 while still building with JSF1.1. This is necessary due to a major design flaw in JSF, where adding methods in new spec releases breaks old code. When running in a JSF1.2 environment, Tomahawk's code checks whether the JSF1.2 method getELContext is present on the FacesContext instance (which was the Orchestra one). It was found (a Method object was located), so Tomahawk invoked it. But that Method was attached to a package-scoped class and therefore not invokable.
As far as I can see, Tomahawk's approach is ok (although it does scare me that tomahawk is wrapping each FacesContext instance, just by being in the classpath). I hadn't considered things wrapping orchestra's FacesContextWrapper and then using reflection to invoke standard api methods on it.
Note that Tomahawk does not have separate JSF1.1 and JSF1.2 flavours; it implements just JSF1.1 except for the odd workaround in situations like this where the JSF spec is not backwards-compatible.
Do you think there is something wrong with either Tomahawk or Orchestra here (except the logging issue I noted, and possible delegation problems as described in