I don't see why there is a check on the default value S.contextPath : when we pass an explicit contextPath then it means that we want to always use it, and not only when there is a issue leading to an empty one...
So it could be simplified to RedirectTo(changeRequestLink(id, contextPath))

And I'm not even sure that S.contextPath == "" is disallowed, in a server with only a single webapp

alas, RedirectTo automatically adds the context path as a prefix when S.contextPath is set , i.e. calling RedirectTo(changeRequestLink(id)) when S.contextPath is set would return something that starts with rudder/rudder/...
I agree that this solution is not the most elegant ; could there be another way to do this ?

So, to keep the API of the link utils look predictable, I suggest to redefine another RedirectTo that skips the check on the context path, since the issue is that the current one adds the context path wrt some logic, and because we don't want that logic when we pass an explicit contextPath.

It would then end up into :

  if (S.contextPath != contextPath) {
    RedirectToStrict(s"${contextPath}${baseChangeRequestLink(id)}")
  } else {
    RedirectTo(baseChangeRequestLink(id))
  }

if I'm not mistaken

if used in with other IDs which are mostly strings, this has some XSS vulnerability because the location is not escaped.
So it should keep the same security guards as in the Lift code with encJs