We already have other classes that really are contexts, such as the SessionContext. These are about something fundamentally different: providing information about the... context in which an operation happens.
The "Context" suffix leads to unclear names for DSL interfaces. If we consider the interface to be a context, we intuitively want to name it according to which context it represents . See for example SearchQueryResultDefinitionContext: it's awkward, but we can't tell what the context is because this interface is returned by methods in different modules. Then we have SearchQueryResultContext (after the result has been defined) and SearchQueryContext (after the ... query has been defined?). It's all inconsistent.
With a "Step" suffix, it would make more sense to name the interfaces after what their main focus is than after where they come from. We could go with SearchQueryResultStep, SearchQueryPredicateStep, SearchQueryOptionsStep, which would be straightforward.
Similarly strange is SearchPredicateFactoryContext, which could become SearchPredicateTypeStep.
A "Step" suffix, in my opinion, makes it clearer that the object is transient by nature and should not be stored for later re-use, in an object for example.
The change should not affect uses of the DSL much, since the DSL objects are generally not stored in variables. So the refactoring should not impact many tests, in particular.
I will try to submit a PR soon.