Ah, looks like bad UX. Moreover, now C# supports "value arguments by ref".

now C# supports "value arguments by ref".

Can you please elaborate that? Do you mean MethodName(ref int id)? If so, then powershell already supports it via [ref].

It seems I did not understand my idea myself:-)

PowerShell like to convert to/from string - 1 + "2" returns 3. So if we accept a string in the test I'd expect that we convert the int to string and ReadOnlySpan<char>.
Perhaps there is more complex scenario. If a parameter type is Span I'd expect that we can able to convert the int to Span too and accept array of int-s.

If this is possible, you can do this in the next PR.

I don't think that's a good idea. Passing arguments to a ByRef-like parameter should be explicit, and I don't think we should do a second layer conversion from the argument to the types that might be able to implicitly/explicitly cast to the target ByRef-like parameter type.

An extreme example: string can implicitly cast to ReadOnlySpan<char>, and any value can be converted to a string in powershell.

With the implicit cast in C# what is a difference string from ReadOnlySpan<char>? Currently CoreFX has overloads with string parameter as wrapper on methods with ReadOnlySpan<char>. We can free use any of the overloads - no difference in result.
Now let's look PowerShell behavior.
function Test1([string] $var) and function Test1([int] $var) both accepts 123 and "123".
If they will be methods we see the same.
Then if it is a binary method with string parameter we see the same. But if it is ReadOnlySpan<char> we get an error.
Seems as minimum we should consider a string as special case.
As maximum perhaps we can discover that there is more common scenarios.

The purpose of this PR is to make PowerShell able to interact with libraries that only exposes APIs with ByRef-like parameters. When there is an equivalent wrapper API, there is no point to call the ByRef-like parameter based API in PowerShell.

As for the conversion, string and ReadOnlySpan<char> are two different types with different semantics, and having implicit casing support between them doesn't change that. PowerShell doesn't support two-layer indirect conversion, for example, PowerShell supports [FileInfo] -> [string], and [string] -> [type], but [FileInfo] -> [type] will fail, even if the FileInfo object can be converted to a string value that can be converted to a type:

$a = [System.IO.FileInfo]::new("string")
$b = [string] $a
$b
> string

$c = [type] $b ## success
$d = [type] $a ## fail
Cannot convert the "string" value of type "System.IO.FileInfo" to type "System.Type".
At line:1 char:1
+ $d = [type] $a
+ ~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidArgument: (:) [], RuntimeException
+ FullyQualifiedErrorId : ConvertToFinalInvalidCastException

Well, then it's best to explicitly indicate in the documentation why this does not work otherwise there will be a lot of questions.

The same. new("abc") vs new(12)

new(12) is to use an integer to test the "not castable" scenario. What is your suggestion to change?

Update-TypeData can be used without creating a file if you'd prefer.

Indeed - much easier. Or is there some reason to use the file?

No particular reason, I just went with the file without considering other options ;) I will change to simply the test.

Updated to use Update-TypeData -TypeName -MemberType ...

Indeed - much easier. Or is there some reason to use the file?