Please add a test for something along the lines of echo '11:1' | grep '.*:.'. The : part is important too to avoid interpreting it as a drive latter

This change only impacts expansion of wildcard characters. ':' isn't a wildcard character so I don't see a reason to add this test.

I think the colon is an issue in the FileSystem Provider and should probably be in those tests

Steve - I'm not sure i understand your comment. I'm not testing the file provider here. I'm just making sure that quoting suppresses globbing. Specific issues with the filesystem provider are orthogonal.

Didn't notice that the test didn't involve cmdlets

ast makes storing the extent no longer necessary, right?

I mean - extent should always be ast.Extent, so we could remove the field and use a property instead.

This API is used in many places where the AST is not available e.g. the PowerShell API, F&O. In those cases dummy extents are explicitly passed in. So both the Ast and extent members are required.

We could introduce a dummy ast for the dummy position.

My thinking - if the normal case is a script, we optimize for that case. If the field is typically redundant, we use less memory, generate less code (the push of the extra parameter), and reduce the number of fields gc needs to visit.

I think a dummy AST is overkill. Reworking the API to use dummy extents if the AST is null, etc. is probably the best solution but that's out of scope for this issue.

Adding a new parameter will bloat the generated code significantly - this is an extra parameter for every argument on every command invocation. We should avoid that if there are alternatives.

I'm still not happy with storing 2 references a typical script has a ton of these instances.

What if we use something like:

    private object context;  // Instead of storing Extent and Ast
    // ...
    internal Ast ParameterAst { return _parameter?.context as Ast; }
    internal IScriptExtent ParameterExtent {
        return _parameter?.context as IScriptExtent ?? (_parameter?.context as Ast)?.Extent;
    }
    // etc.

The same applies here regarding ast and extent.

Same response as above - the API is used in places where there is no ast.