Write-up is highly Windows-centric (though not irrelevant elsewhere).
One thing that is regretfully ignored in discussions of async, tasks, green threads, etc. is that there is no support/consideration for native (reliable/efficient) thread-local variables. If you're lucky you'll get a warning about "don't use them".
Then - ignoring dunders that have weird rules - what, pray tell, is the point of protocols, other than backward compatibility with historical fragile ducks (at the cost of future backwards compatibility)? Why are people afraid of using real base classes?
The fact that it is possible to subclass a Protocol is useless since you can't enforce subclassing, which is necessary for maintainable software refactoring, unless it's a purely internal interface (in which case the Union approach is probably still better).
That PEP link includes broken examples so it's really not worth much as a reference.
(for that matter, the Sequence interface is also broken in Python, in case you need another historical example of why protocols are a bad idea).
chunks: [AtomicPtr>; 64], appears before the explanation of why 64 works, and was confusing at first glance since this is completely different than the previous use of 64, which was arbitrary. I was expecting a variable-size array of fixed-size arrays at first (using something like an rwlock you can copy/grow the internal vector without blocking - if there was a writer, the last reader of the old allocation frees it).
Instead of separate flags, what about a single (fixed-size, if chunks are) atomic bitset? This would increase contention slightly but that only happens briefly during growth, not accesses. Many architectures actually have dedicated atomic bit operations though sadly it's hard to get compilers to generate them.
The obvious API addition is for a single thread to push several elements at once, which can be done more efficiently.
Aside: Note that requests is sloppy there, it should use either raise ... from e to make the cause explicit, or from None to hide it. Default propagation is supposed to imply that the second exception was unexpected.
For an extension like this - unlike most prior extensions - you're best off with essentially an entirely separately compiled copy of the program/library. So IFUNC is a poor fit, even with peer optimization.
In practice, Protocols are a way to make "superclasses" that you can never add features to (for example, readinto despite being critical for performance is utterly broken in Python). This should normally be avoided at almost all costs, but for some reason people hate real base classes?
If you really want to do something like the original article, where there's a C-implemented class that you can't change, you're best off using a (named) Union of two similar types, not a Protocol.
I suppose they are useful for operator overloading but that's about it. But I'm not sure if type checkers actually implement that properly anyway; overloading is really nasty in a dynamically-typed language.
All of these can be done with raw strings just fine.
For the first pathlib bug case, PATH-like lookup is common, not just for binaries but also data and conf files. If users explicitly request ./foo they will be very upset if your program instead looks at /defaultpath/foo. Also, God forbid you dare pass a Path("./--help") to some program. If you're using os.path.dirname this works just fine.
For the second pathlib bug case, dir/ is often written so that you'll cause explicit errors if there's a file by that name. Also there are programs like rsync where the trailing slash outright changes the meaning of the command. Again, os.path APIs give you the correct result.
For the article mistake, backslash is a perfectly legal character in non-Windows filenames and should not be treated as a directory component separator. Thankfully, pathlib doesn't make this mistake at least. OTOH, / is reasonable to treat as a directory component separator on Windows (and some native APIs already handle it, though normalization is always a problem).
I also just found that the pathlib.Path constructor ignores extra kwargs. But Python has never bothered much with safety anyway, and this minor compared to the outright bugs the other issues cause.
One problem is that Rust doesn't support tagged unions. enum is regrettably solving a different problem, but since it's the only hammer we have, it's abused for this kind of thing. This often leads to having to write match error ... unreachable.
The default handling is pretty important.
What I find more interesting are 1. the two-argument form of iter, and 2. the __getitem__ auto-implementation that causes there to be two incompatible definitions of Iterable.
(btw your comments are using accidental formatting; use backticks: __next__)
The problem with pathlib is that it normalizes away critical information so can't be used in many situations.
./path should not be path should not be path/.
Also the article is wrong about "Path('some\\path') becomes some/path on Linux/Mac."
If by "down" you mean completely down, it's probably just you; I don't think I've ever seen a failure that didn't go away after refresh.
Flakiness for specific features (often subscribe/block, and once notifications) have been more common.
That still doesn't explain why duck typing is ever a thing beyond "I'm too lazy to write
extends BaseClass". There's simply no reason to want it.