Not currently, but this looks to me like a regression, because I've seen something very similar before. I believe Visualcron used to use (and may be using again) eager parsing for variable expressions, and is finding the
closest to the end of the line, and therefore looking for a user variable named
dstsautosaves)}\trades_intraday.csv | where-object {($_.Customer -like "10*"
and not finding one. (Which I would say is a good thing; that would be a terrible name for a variable.) Note that in your code that works, without the where-object block, there isn't another thing on the line that could look to Visualcron like the end of a Visualcron variable expression.
My workaround at least
used to be to put a space before any closing curly brace that is supposed to be powershell syntax and
not the end of a Visualcron expression. Example:
$RESULTS=Import-Csv {USERVAR(dstsautosaves)}\trades_intraday.csv | where-object {($_.Customer -like "10*") }
Also note the inverse implication: that Visualcron will probably also get mixed up if you put a space between the closing paren and the brace when they ARE supposed to end the Visualcron expression.
In your example, the parentheses in the where-object block are also superfluous, but you mentioned specifically that this was a simple example, so I assume you may have cases that do need them.
I think this may also only happen within the context of a single line, but I'm not 100% sure.