I was very wonder to read comments in the method above.
Is the method used for both FromSession and ToSession?
If so I wonder again because obviously the method is only for FromSession scenario.

This is independent from ToSession and FromSession, it applies to all dynamic parameters

I say that original design was broken - it makes no sense to check the path existence if it is on remote.
Next question is does it make sense to check the existence for local path? If it even makes sense this is the wrong place for it - all we need is the providerInstance as you said.

Do we really need globbing? I suggest to make minor breaking change and use GetUnresolvedProviderPathFromPSPath() or GetProviderPath().

Then if providerInstance is null then pathNotFoundOnClient is always true and we always effectively fall back to FileSystemProvider:

        internal object CopyItemDynamicParameters(
            string path,
            string destination,
            bool recurse,
            CmdletProviderContext context)
        {
            if (path is null)
            {
                return null;
            }

            ProviderInfo provider = null;
            string providerPath = null;
            try
            {
                providerPath =
                    context.ExecutionContext.SessionState.Path.GetUnresolvedProviderPathFromPSPath(
                        path,
                        context,
                        out provider,
                        out _);
            }
            catch (DriveNotFoundException)
            {
                // This exception is expected for remote sessions where drives exist in a remote session but not
                // on the client.
            }
            catch (ItemNotFoundException)
            {
                // This exception is expected for remote sessions where item exist in a remote session but not
                // on the client.
            }

            if (provider is null)
            {
                // At this point, we don't know if this is a remote use of copy-item because the FromSession
                // and ToSession dynamic parameters have not been retrieved yet.
                // Ignore these exceptions and use the FileSystem provider as default.  If this is a real drive
                // issue, or if the item does not exist, it will be caught later when the drive or item path is used.
                var fileSystemProviders = Providers["FileSystem"];
                if (fileSystemProviders.Count > 0)
                {
                    providerPath = path;
                    provider = fileSystemProviders[0];
                }
            }

            if (provider is null)
            {
                return null;
            }

            CmdletProvider providerInstance = ExecutionContext.EngineSessionState.GetProviderInstance(provider);
            return providerInstance is null ? null : CopyItemDynamicParameters(providerInstance, providerPath, destination, recurse, context);
        }

I'm not sure what the original design intent was, but the path(s) after globbing are passed down to the provider for dynamic parameters (so null is now possible where it wasn't before, but it's an assert so could have happened in retail builds anyways), so presumably a provider could use that information and we should probably not make that breaking change.

the path(s) after globbing are passed down to the provider for dynamic parameters

so presumably a provider could use that information

This just makes me think that it's much more useful to pass the original path than after globbing, otherwise in CopyItemDynamicParameters there's no way to know that globbing was used. I believe it is more right design and the breaking change is under bracket 3 (unlikely breaking change).

Although if you find it totally unacceptable, it's worth cleaning up the code anyway, like in my sample.

so null is now possible where it wasn't before

providerPath argument is never null in CopyItemDynamicParameters().

Not providerPath, but just path. I think if provider authors would find value in the original search path, we would have heard about it. I don't think it's worth making this change.

Not providerPath, but just path.

I don't understand. The method starts with:

            if (path == null)
            {
                return null;
            }

I think if provider authors would find value in the original search path, we would have heard about it. I don't think it's worth making this change.

I guess nobody uses this :-) I mainly think that the binder is already too slow and we could make it faster.
Moreover, we have already made a breaking change by passing a non-existent file.

I agree that this is code seems wrong and that parameter binding is not the right place to do path validation. My guess is this code was here when copy-item was local only, and then adjusted when copy-item was extended to support remote copy.

I feel it is worth considering a breaking change to re-review this and possibly fix it.

I would prefer to take a small change now to improve the user experience (they would get an error from the provider instead of the parameter binder not helping them understand why it didn't work) and defer any potential breaking change.

This is reasonable. Can you create an issue to track it?