> Is the behaviour you're proposing any different from using `Path.rglob('*')`?

By that logic, we should remove `Path.iterdir()` in favour of `Path.glob('*')`. In addition, having `iterdir` the way it is makes it easy for subclasses to extend its functionality (for example, one of my `Path` subclasses allows a callable to be passed to the `iterdir` which can filter paths)

> One thing you may need to worry about here is the fact that symlinks can have cycles, so you may need to do some cycle detection to avoid creating the dangerous possibility of infinite loops.

I agree, which is the main reason the current implementation in the pull-request is to not resolve symlinks: users can subclass and implement symlink resolving if they want

> There's also the question of whether you want this to be a depth-first or breadth-first traversal, and whether you would want both of these to be options.

As much as I want to say that I don't see a use-case for breadth-first file listing (when I list files, I expect the next file provided to be 'next to' the current file), users currently have no standard-library functionality to perform breadth-first searches as far as I know: they'd have to implement it themself or find it in a third-party library

> Slightly related, pathlib.walk was proposed in the past in python-ideas...

I've never really liked the interface to `walk`, personal preference