Windows glob expansion via wild does not preserve input path separator style

Hi uutils/coreutils team,
I am currently maintaining microsoft/coreutils and ran into an issue regarding Windows glob expansion. I wanted to check if you have encountered this as well, and whether you think this should be addressed at the uutils/coreutils level or via its dependencies.
Here is the related issue for context:
https://github.com/microsoft/coreutils/issues/107
The Problem
When running the following command in Windows cmd.exe:

ls c:/Windows/*.exe

The actual output becomes something like:
c:/Windows\notepad.exe
Instead of preserving the forward slash / from the input pattern:
c:/Windows/notepad.exe
Based on my investigation, this is not an issue with ls's internal path display logic, but rather an artifact of the wild dependency. Since Windows cmd.exe does not automatically expand globs, uutils relies on wild::args_os() for argument expansion. Internally, wild calls glob::glob_with(), which returns PathBuf. On Windows, the newly appended path segments naturally use the backslash , leading to mixed path separators in the output.
What I've Done So Far
I have submitted a fix upstream to the wild repository:
https://gitlab.com/kornelski/wild/-/merge_requests/5
However, the wild project hasn't seen active maintenance for about two years, so I am unsure if or when this MR will be merged. Because of this, I created a mirrored fork on GitHub and applied the fix there:
https://github.com/a-rookie-of-C-language/wild
The latest commit in my fork ensures that the glob expansion preserves the path separator style (/ or ) based on the original pattern.
The Dilemma & Next Steps
I originally intended to integrate this fix into microsoft/uutils-coreutils (which microsoft/coreutils depends on). However, since microsoft/uutils-coreutils is a fork of uutils/coreutils, GitHub's fork architecture prevents me from opening a direct PR to it from my fork.
Therefore, I wanted to reach out to the upstream uutils/coreutils team first: Do you think this fix is valuable for uutils/coreutils as well? If so, what approach would you prefer?
Here are a few paths forward we could consider:

• Temporarily patch uutils/coreutils to point to the patched wild fork via Cargo's [patch] table or git dependency.
• Implement a local workaround/normalization logic inside uutils/coreutils or microsoft/coreutils.
• Wait for the upstream wild maintainer to accept and publish the fix.
• Leave it as-is for now.
  Any other alternative approaches you might suggest.
  Root-cause-wise, I believe fixing this at the wild layer is the most elegant solution. But given the upstream maintenance status, I would appreciate your insights on which approach fits best with your project guidelines.

Start by reproducing ls c:/Windows/*.exe on Windows and read the argument-expansion path using wild::args_os() and glob::glob_with(). Compare the proposed wild fork and upstream merge request, then determine whether the project should patch the dependency, add a local workaround, or wait; done means an agreed approach that preserves the input separator style.