Keeping it consistent with UWP, where we initially got these APIs: https://learn.microsoft.com/en-us/uwp/api/windows.storage.storagefolder.getitemasync?view=winrt-26100

interface IStorageFolder
{
     Task<IStorageItem> GetItemAsync(string name);
}

@dmirmilshteyn if you want to add this functionality, a PR is welcome 👐

I would be down to implement this but there are some open questions I have because it needs to be implemented for each targeted platform.

For Desktop its simple and the name can even be a relative path like mentioned in the UWP docs.
But for Mobile and Browser it gets more difficult (especially the relative path thing).
So should it work with relative paths? e.g:

Android uses there AndroidUri and you can't just get a File by the Filename (at least what I saw) without iteration over the directory because it abstracts the Filesystem away (items could come for a server, etc). This nullifies the performance gains expected from this issue.

The Browser can give you the Item by name getFileHandle or getDirectoryHandle but I dont know if it can handle relative paths.

I didnt look into IOS.

On browser this new API should map to:
FileSystemDirectoryHandle.getDirectoryHandle()
FileSystemDirectoryHandle.ƒgetFileHandle()

Which gives an idea, that we should consider having two different APIs instead of one shared:

interface IStorageFolder
{
     Task<IStorageFolder> GetFolderAsync(string name);
     Task<IStorageFile> GetFileAsync(string name);
}

On iOS I don't see any dedicated FileManager API. But typical FileInfo C# apis should work there too.

On Android, I am not an expert, but seems like the same Query API, as we use for GetItemsAsync(), is recommended there too.

So should it work with relative paths? e.g:

This proposal is specifically about retrieving single file/folder from the known folder.

Thank you. I will make an initial implementation with "two different APIs" approach.