Callback or more detailed report from SHACL validation

Summary:
Could we make the ValidationContext constructors protected and use instance methods instead of the current static factory methods (at least for create(ValidationContext) so that a subclassed ValidationContext can be provided for validation that can also be propagated into the sub-evaluations?

Explanation:

I'm working on code that quite intimately builds on jena's SHACL validation.
Here's what I'm trying to do: There is a set of nodes V in the data graph G that I am trying to find substitutions for by other RDF nodes. A substitution is valid if no shape has a violation. Now for figuring out which substitutions might be valid, it is not enough to know that shape S is violated on focus node F - I need to know why exactly - i.e. which of my substitutions made the validation fail. I already have a system in place that notices which nodes in V (or their respective substitutes) are looked at during evaluation of S. Also, If the violation is of a simple property shape, I can follow the sh:ResultPath of the report from F to get to the node; however, if the shape uses an aggregate like sh:xOne, or a sh:node the report does not help me find the culprit, I just know it's one of the nodes that were looked at.

I have two ideas how this could be fixed for me:

More detailed report
An optional, non-standard report could be generated that always allows me to figure out which of my substitutions for nodes in V (or lack thereof) caused the violation. Maybe it would be enough to pass the validationreport of sub-evaluations through to the main one.

or

ValidationCallback
A callback that I can provide for an evaluation, either as a method param to VLib.validateShape(), as an optional member in the ValidationContext, or in a ThreadLocal. The latter may be a problem if evaluation is done in multiple threads, so maybe that's not such a great idea.
The callback would need to be called whenever a reportEntry is added to the context - also in sub-evaluations that use a new context.

One way with minimal impact on the codebase to achieve at least the second of these solutions would be to allow me to extend the ValidationContext (currently not possible because of the private constructors) and to allow me to return my subclassed ValidationContext in ValidationContext.create(ValidationContext) - and maybe also in the other, currently static, factory methods. If that was possible, I could easily intercept reportEntry methods, which (I hope) is enough.

If that is an option, I'll provide a PR, so that I can make sure the suggested changes really do solve my problem.