Thanks for the PR, however, I don't think this is needed.
Cache path is an internal implementation detail so it shouldn't show up with the main info, just like nuget restore path or package store path doesn't show up on dotnet --info. IMHO it's enough that it shows up in debug output and is documented in the documentation.

dotnet --info does not show the NuGet or package restore path because those are SDK-specific details. You can get to some of that info through more specific sub-commands like dotnet nuget locals --list all.

Also, dotnet script --info already does far more than dotnet --info, like checking for the latest version and providing instructions for updating so it seems to have deviated from its role model anyway.

it shows up in debug output

Fair point, but the problem is that the caching information is only emitted when a build takes place (when cache is missed). On subsequent runs with a cache hit, there is no way to discover or get back that information without changes the script source to cause an invalidation. All I see is:

PS> dotnet script -d test.csx
dbug: Dotnet.Script.DependencyModel.ProjectSystem.ScriptParser[0]
      Parsing A:\dotnet-script\bar.csx
Hello!

I agree it's an internal implementation detail but it's a substantial performance feature that leaks into the environment and so it's information that can potentially help with diagnostics. While the temp path is documented now, 😉 you still have to go looking for it and the README.md in the master branch, which by the way, won't necessarily reflect your deployed version. If not, you have to go looking for the README.md corresponding to the version you're using, but then that may not always have the info.

I think the best solution is to just add "running from cache... {path}" to the debug output

Okay, I can compromise with that. See 8c67160.