Part of the problem is that GetMergedCommandParameterMetadataSafely isn't actually safe due to #4003. Since getting parameter metadata can cause PowerShell code to be invoked (dynamic params), if you just make the dictionary itself thread safe you're more than likely going to see a lot more harder to track state corruption.

A simplish fix would be for PSSA to maintain it's own ConcurrentDictionary<CommandInfo, Dictionary<string, ParameterMetadata>>. Though iirc that API doesn't actually ensure that two "create" delegates won't run concurrently, just that the actual dictionary add won't. If that's correct then you'd probably have to roll your own version with a lock.

As for fixing the problem in PowerShell itself, I think fixing #4003 is the only option. That said, there's a reason it's sat open for almost three years, it's difficult to solve without a probably sizable (but sort of unknowable) break.

@SeeminglyScience Thanks for the valuable input and specific references. :-)
I remember talking to @daxian-dbw about this issue in a general way where it happened in a different scenario (Test-ModuleManifest was not thread safe and could be fixed in PSSA by limiting its concurrency in PowerShell/PSScriptAnalyzer#1258). In this scenario the parameters property comes from the CommandInfo cache of PSSA where limiting concurrency is not only hard from a consumers point of view but also comes with performance implications (a lot of the perf improvements in recent version were done by getting rid of fat locks and using .Net's built in and thread safe ConcurrentDictionary)...
A suggestion was also to try to force evaluation of the property in the runspace that originally created it. I tried to call the .Parameters property right after Get-Command gets queried the first time and do something with so that the compiler doesn't optimize the call away and this did not help. All I can think of now is to add the parameters to the cache as well (bad in terms of memory usage) or not use the cache in this instance.

This pull request has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 15 days. It will be closed if no further activity occurs within 10 days of this comment.

Closing as PSSA implemented the workarouns to catch the exception when it happens for a command from the cache and just ask for a fresh new object.
Since the other referenced PowerShell issue where the root cause lies, is still open, I'll close the PR then