And see also #2497

Is this issue sufficiently well defined to be suitable as a GSOC starter issue? Or could it be written in such a way that we can let GSOC applicants work on it?
(Also pinging reviewers of PR #3935 @hmacdope @richardjgowers @IAlibay and maybe @RMeli may be interested.)

Adding this to 3.0

I had some time to take a look at this issue right now and from the looks of it and running some code SingleFrameReaderBase can currently handle both str and pathlib as an input. would it be enough to add tests, that showcase that SingleFrameReaderBase can handle both inputs correctly or is the upstream to proto and the addition of NamedStream still required?

I think the aim of this is to find any points we are loading files and support pathlib as well as a str. Best bet is to look for spots where files are loaded outside of ReaderBase objects. If there are no tests that cover this already though would welcome a PR adding tests. Unsure about NamedStream

If i understood correctly the idea is to see if SingleFrameReaderBase would need the same adjustments that were done for ReaderBase in PR #3935

with the case that is not covered by ReaderBase being the case of loading single frame formats, since they would be recognized with SingleFrameReaderBase. So the idea would be to use

u = mda.Universe(file.gro)

with file.gro being a single frame format with one frame that is recognized by SingleFrameReaderBase and test if it would recognize correctly a pathlib input as well as a str input for file.gro

currently the tests do test pathlib and str input for ReaderBase, but only test str input for SingleFrameReaderBase in the tests.