Wrapping exceptions does throw away information that the caller may want, so I'm in favor of framework code just emitting Exceptions. The nightmare that is jmx is the best example of way too specific of throws clauses and exception wrapping rules.

I don't agree with a black/white assesment of checked/unchecked exceptions. The problem is that this distinction cannot be made by the exception emitter. Its a function of the caller state machine. If the state has no transitions for any exception, every exception is unchecked. If the state has fine grained events based on the exception type, every exception is checked.

You should start a java7 campaign to make all exceptions unchecked by default with annotations that map to on exception handlers along with a Thread active exception state map that indicates which exception types are of interest to the caller at any given point in time.

The flip side argument for frameworks using checked exceptions has to do with static code auditability. If I'm writing a framework in an environment that requires every security issue to be logged, frameworks that detect security issues could throw a checked SecurityException and all caller code "analyzed" for proper handling of the exception. I think this would be better handled by being able to register a SecurityException handler at the jvm root thread group such that every call stack inherits the handler, but that is not the current exception model.