The SPARQL parser recognizes and extracts this information and attaches it to the AST, but the query plan generator does not yet use the attached bindings. The simplest way to integrate those BINDINGS is to pump them into a named solution set and then INCLUDE that solution set within the top-level WHERE clause.
However, bigdata accepts IBindingSets pretty much everywhere. In fact, they are accepted at the IRunningQuery, the ASTOptimizers, etc. Just not ASTEvalHelper. The more general solution is therefore to simply accept multiple solutions into the query, do the static analysis of those solutions (the SolutionStats class) and then attach that analysis to the QueryRoot. The SolutionStats can then be leveraged in the ASTOptimizers.
The openrdf platform allows the caller to specify a single BindingSet as input to the query. That pre-existing API needs to be reconciled with a BindingSet flowing into the query through the Bindings clause. I think that the right way to reconcile these things is to treat the caller given BindingSet as a constraint which must be applied to every solution in the BINDINGS clause. If this results in conflicting bindings for a given source solution from the BINDINGS clause, then there are no solutions to the query for that source solution.
Thus, another way to look at this is that the BINDINGS clause attached to the QueryRoot replaces the BindingSet or IBindingSet flowing into the query. They are basically different approaches to capturing the same information and just need to be reconciled.
See https://sourceforge.net/apps/trac/bigdata/ticket/412 (StaticAnalysis#getDefinitelyBound() ignores exogenous variables)
See https://sourceforge.net/apps/trac/bigdata/ticket/449 (SPARQL 1.1 Federation)
See https://sourceforge.net/apps/trac/bigdata/ticket/267 (Support evaluation of 3rd party operators)