The mixed use of slashes as it relates to filesystem paths isn't an issue, PHP handles it just fine. Changing the return value will be a problem because at that point the path is supposed to be URI friendly, meaning only using / and not mixed use (or even worse, \). So if there's anything to be done here, it's calling JPath::clean($file, '/'); before any other processing happens to ensure that the only URI segment that isn't being built by that method has its slashes standardized.

@mbabker are you saying each of these should be removed & it be cleaned elsewhere?

// If the file is in the template folder
$path = \JPath::clean(JPATH_THEMES . "/$template/$folder/$file");

lines 398-399 .. I already removed it around the return.

The only change I would make, not knowing what is prompting this to begin with or what the real bug being addressed here is, would be to put a $file = \JPath::clean($file, '/'); call here. All of the other segments are being built by our code, there is no need to clean them. Everything else is overkill or will break things (remember PHP on Windows could care less if you put your path in as C:\Web Server\Joomla/administrator/index.php, filesystem functions will work OK, what is more important is if you are using any part of that file path as a URI that the slashes are standardized to / and as a UX thing if displaying the full path to the user I would use OS native separators, in which case I'd run that through JPath::clean() before displaying it).

@mbabker ok, what prompted this is I was having some issues getting htmlhelper to function properly and once we got it narrowed down I discovered that if it was called with '/filename' instead of 'filename' it would put a double // and mixed separators.
I'll make the change and recommit it.
Thanks for the help and understanding!!

I have tested this item ✅ successfully on 07cf909

closing since we have an updated pr.