After performance improvements in PR #2822 we still have some problems (edited by @daxian-dbw):

1. Hung or Freeze of a progress pane. If Write-Progress or the corresponding API is not called very frequently, new progress record may not be rendered for a long time, which means the user won't see the new progress update during that time. This is because we now use a timer to indicate whether a call to Write-Progress or the corresponding API would do the actual rendering, so in case there is no more incoming calls, new progress record updates would not be rendered.
2. If Write-Progress frequently updates a progress pane and the script makes output to console the user sees that the display flickers. This can be illustrated by 1..1e4 | % { $_;Write-Progress "..." -PercentComplete ($_*100/1e4)}.
3. ResetProgress() - In the case of multiple runspaces with one Host, the finished pipeline will remove the progress bar that is still used by unfinished pipeline from another runspace. This is an existing problem even before the fix in Improve a progress pane performance (one thread) #2822. If a Host is used by multiple runspaces and the pipeline threads from them are all writing progress bars, then it's almost for sure a mess. We didn't see reports on this before so assuming this is rare to happen.
4. Write-Progress does not work correctly with nested operations. #5370 - With Write-Progress -Completed in nested scenarios we need a delay Start-Sleep 1 to get screen update in follow Write-Progress.
5. Tons of allocations. Perhaps we could add overloads with a struct.
6. Progress bar remains despite Completed record in progress stream (now with portable repro) #12541 - Cmdlet authors want to show 100% complete result. But if they would use -Complete users never saw the message. If they would write a message without -Complete the message displayed until pipeline finished.