UriBuilder style is about accumulating the state and then doing a build with one of the build() or buildFromEncoded() methods.
For example, one can request that URI is built with the assumption that all template vars have already been encoded (buildFromEncoded) or that path variable values containing a slash have to be encoded (build() accepting an encodePathSlash parameter).
The introduction of resolveTemplateFromEncoded() and resolveTemplate() accepting encodePathSlash makes the existing style involving build() methods less consistent. For example, resolveTemplate() accepting encodePathSlash may be followed by the build method providing the opposite encodePathSlash value.
Similarly, the same applies to a new builder method, toTemplate(). One can have resolveTemplate() accepting encodePathSlash called a number of times with different encodePathSlash values and it will not be obvious at toTemplate() time which path variables have to be treated specifically and which not.
The above may seem like a very minor issue - but IMHO the core API construct such as UriBuilder should not have any space for the ambiguity.
For example, arguably, a support for encoding path slashes could've been implemented differently to having a build() method accepting 'encodePathSlash'. But the current solution fits into the UriBuilder build style, specifically, the decision to customize is done at the final build step.
Thus I propose to optimize a bit the way resolveTemplates support is done.
At the bare minimum: remove resolveTemplates accepting encodePathSlash - this is already covered by a related build method; to get the same supported at the toTemplate() level do add a new toTemplate(boolean encodePathSlash) method or modify the existing one.
Next, unless a support for having a combination for already-encoded and not yet encoded template var values is absolutely required, repeat the same process for resolveTemplatesFromEncoded - drop them and introduce a related toTemplate method
IMHO - this will make UriBuilder API and quite minimalistic again