Use case for initial bindings

[namedgraph]

I'm upgrading Jena dependency from 4.7.0 to 6.0.0 and one of the main pain points is the removal of initialBindings.
I sort of understand the reasoning behind it, but aren't there situations where it is appropriate to use initial bindings? But in 6.0.0 there is no mechanism anymore for doing that?

For example, 6.0.0 based code with substitution requires modification of the query algebra

Query query = QueryFactory.create(queryText.getString(), baseURI);

// Inject BIND(?_this_bind AS ?this) into the WHERE clause.
// This keeps ?this as a variable in the CONSTRUCT template (not a written blank node),
// so the template picks up the concrete node value — preserving blank node identity.
// See: https://github.com/apache/jena/issues/3267
Var bindVar = Var.alloc("_this_bind");
ElementGroup group = new ElementGroup();
group.addElement(query.getQueryPattern());
group.addElement(new ElementBind(Var.alloc(SPIN.THIS_VAR_NAME), new ExprVar(bindVar)));
query.setQueryPattern(group);

Binding binding = BindingFactory.binding(bindVar, instance.asNode());

try (QueryExecution qex = QueryExecution.create().
        query(query).
        model(instance.getModel()).
        substitution(binding).
        build())
{
    instance.getModel().add(qex.execConstruct());
}

where as the old version was simply

Query basedQuery = new ParameterizedSparqlString(queryText.getString(), baseURI).asQuery();
QuerySolutionMap bindings = new QuerySolutionMap();
bindings.add(SPIN.THIS_VAR_NAME, instance);

// execute the constructor on the target model
try (QueryExecution qex = QueryExecution.create().
        query(basedQuery).
        model(instance.getModel()).
        initialBinding(bindings).
        build())
{
    instance.getModel().add(qex.execConstruct());
}

I am struggling to understand what exactly has substitution over initialBindings improved in this situation?
Doesn't the simplicity of the original solution indicate that it was indeed the appropriate solution?

[namedgraph]

Related to #3267 as the comment says

[namedgraph]

I have unit tests that need to pass as well as user-defined constructors, so the updates are not helpful.

I have an initial blank node and am "applying" CONSTRUCT constructors on, augmenting its properties. That conceptually looks to me like an actual initial binding more than susbstitution.

And the point re. increased complexity still stands.

[afs]

I have unit tests that need to pass

An issue at your end.

And the point re. increased complexity still stands.

1. The description misses important information.
2. You have not addressed the reasons for change.

[namedgraph]

My examples are respective solutions side-by-side that produce an equivalent result with 6.0.0 and 4.7.0. That result is something like

[
  dct:title [ a xsd:string ] ;
  dct:description [ a xsd:string ]
]

obtained by taking an initial blank node (?this = _:bnode) and applying constructors in the form of CONSTRUCT queries such as

CONSTRUCT { ?this dct:title [ a xsd:string ] } WHERE {}

and

CONSTRUCT { ?this dct:description [ a xsd:string ] } WHERE {}

Yes I know the ranges of those DCTerms properties are misused here but that is besides the point.

I understand that initial bindings were often misused instead of substitution. But that does not imply that the initial bindings do not have legitimate use cases? Could they not remain exposed by a lower-level API such as QueryExec?

[namedgraph]

Full code: https://github.com/AtomGraph/Web-Client/blob/master/src/main/java/com/atomgraph/client/util/Constructor.java#L75

[namedgraph]

So not a use case for initial bindings? :) The new code, despite producing the same result, is much less intuitive to me.