-- was implemented there was a specific serialisation check in place that blocked RunParamaterValue from adding to the params array that provides access to the real object, rather than a string representation of it. JENKINS-27295
On some recent testing if an input step is used to request a build be selected:
Then the object returned is the Run object that you can then do getDisplayName or getDescription on ...
If instead of an input step a build parameter is used:
Then the variable (direct or through env.foo) is just the $BUILD_URL of the build selected as a string, and there's no Run object on params to access more detail about that build.
These should be made consistent so that either the input step only returns the string job_url to match the build params, or the Run object itself should be accessible when using a build parameter ... naturally I'd prefer the latter as it's way more flexible.