IMO, the problem is really just a matter of better identifying and encapsulating the different phases of building and consuming statements and result sets. So lets use this investigation to start better defining that and maybe leveraging that as the solution.

First, lets take the case of performing a select query and processing results:

The first step is identifying that we in fact need to perform a select (or possibly a procedure call returning results) and that there is some form of "result processing" that builds the end result. Today this is all bundled into Loader which is very inflexible in many scenarios (see my "Loader Redesign" proposal[1]). However, for this work think we still need to stay within the Loader design; just saying that I think we can take some of the redesign proposals and apply them with that.
Next we actually need to build the statement, which might mean preparing a statement or building a callable statement.
Then we "prepare" the statement in terms of setting timeouts, registering IN/OUT parameters for procedure calls, etc (I realize using the term "prepare" here is confusing with the fact that JDBC calls the statements prepared after creating them; better phrases/terms welcome).
Then we bind any input parameter values.
Then we execute the query
If the query resulted in ResultSets, we apply the "result processors" identified in step 1 to any results.

I say that this is important because that really is the reason we did proxying - to tie in to each of the above phases in various ways. For example, whenever a Statement is built (step 2) we want to keep track of it as part of the JdbcResourceRegistry, we want to track all ResultSets too. Logging. Etc.