Poweshell Version: 6.1.4
ErrorVariable is not set when an error happens as seen in the screenshot below. However, if you use + append sign in front of the variable, it works.
Below you will see that I try to run the command without the + to set the ErrorVariable, which won't work. Later, it works with + with a different parameter. In the first case, outputting the $errorVariable does not display anything.

ErrorVariable should be working without the need of + append operator in front.
ErrorVariable is not set when an error happens.

Can you please test with the latest release and see if this is still an issue? 馃檪
Also, is this occurring with _all_ cmdlets, or just that one cmdlet you're using here?
@vexx32 Latest release like on the Powershell Core version 7 line or version 6 line? Because I have downloaded it from here https://github.com/PowerShell/PowerShell/releases/tag/v6.2.2 which is latest for the version 6 line.
Also it seems to be happening in other command line environments too. This one, for instance, from ConEmu:

GitHub
PowerShell for every system! Contribute to PowerShell/PowerShell development by creating an account on GitHub.
Latest release, period. If it's already fixed in PS7 it's likely that it won't be backported to 6.1.x branch. Typically only critical / security fixes are backported at the moment.
Console environment shouldn't matter, PowerShell is PowerShell, wherever you're running it. 馃檪
@vexx32 Oh wait, you said cmdlet, I thought you meant cmd environments. Let me try with other cmdlets.
I was able to reproduce the issue on PowerShell 7 preview 3, and it seems specific to Get-InstalledModule. For example, the following works fine:
gps -id 123323123 -ev foo
$foo
I guess that makes this a PowerShellGet issue?
Genuinely not sure how you'd author a cmdlet that breaks this behaviour, though. I didn't think it could be done.
@SteveL-MSFT are you familiar with this cmdlet at all? Might be worth a look as you guys get towards PSGet 3.0, if this cmdlet is being retained going forward.
PowerShellGet has a rather...creative implementation.
@tarikguney Please move the issue to PowerShellGet repo.
This issue has been marked as external and has not had any activity for 1 day. It has been be closed for housekeeping purposes.
Most helpful comment
I guess that makes this a PowerShellGet issue?
Genuinely not sure how you'd author a cmdlet that breaks this behaviour, though. I didn't think it could be done.
@SteveL-MSFT are you familiar with this cmdlet at all? Might be worth a look as you guys get towards PSGet 3.0, if this cmdlet is being retained going forward.