Workaround, based on the path info in the error message:

$ mv var/cache/prod var/cache/prod-old
$ bin/console cache:clear --env=prod

 // Clearing the cache for the prod environment with debug false

 [OK] Cache for the "prod" environment (debug=false) was successfully cleared.

Does the issue persist or are you now able to run the cache:clear command without any errors after applying your workaround?

The workaround is to manually remove the entire cache. The issue does not persist after clearing the cache. However, because the cache:clear command is broken in this scenario, I can easily reproduce the issue by restoring the cache.

This could be either a console issue or an upgrade documentation issue or both. I doubt the problem is specific to the kernel.

Upgrading to 7.0 from which version ?

I'll check the composer.json log for details...

5.4 in January
6.3 in August
6.4.2 yesterday
7.0.2 yesterday

this is weird. In 6.4, the generated container should not have ContainerFLCn0pU\App_KernelProdContainer::getParameter(string $name). Was your prod cache really generated by Symfony 6.4 before the upgrade to 7.0 or have you tried upgrading your prod cache directly from 5.4 to 7.0 ?

The generated cache is not compatible with 2 major versions higher.

As I mentioned in the top post, this machine is rarely ever in prod mode. So yes the cache was either from 5.4 or 6.3. The docs don't say anything about "upgrading your prod cache".

https://symfony.com/doc/current/setup/upgrade_major.html

I am not convinced that having an application pending over several major versions, but never deploy them to production is a use case common enough to be explicitly mentioned in the upgrade guide.

In any case this then doesn't seem to be an actual issue with the code then, but please feel free to open an issue in the docs repository if you thin that the docs can somehow be improved around this topic.

I am not convinced that having an application pending over several major versions, but never deploy them to production is a use case common enough to be explicitly mentioned in the upgrade guide.

Slightly off topic but following the best practices from the same docs, the prod environment is on the live server and the dev is on a separate machine with different local configs for debugging, meaning they have separate caches. I don't see how that's not a common use case?

Maybe I misunderstand your previous comment then. Having the dev environment locally when debugging and prod on production is of course a common use case and how you should work with your applications. But that doesn't explain why your cache would need to "jump" from 5.4 to 7.0.

Cache needs to jump based on how often (if ever) the config is changed on the dev machine. Essentially because the dev machine almost never needs to use the prod cache, and because the upgrading instructions don't direct any manual changes to either the config nor the cache itself. And you're saying the console is incompatible with doing it that way, which is just new info from my perspective.