pg explained that this interface change was not necessary, but I'd like to point out why I think it's actually a bad thing. I do not mean to rail against you or your idea, but I think this is a situation that demonstrates an important idea about system IO in general.

First, I think it's helpful to explain that IO operations usually follow the pattern of just do it, followed by check if it succeeded. This is to prevent race conditions. If there is any time at all between when you check if you can do something, and when you actually try to do it, things could have changed. To prevent that, we just ask the operating system to do something for us. The operating system attempts to do it, and tells us if it succeeded or failed. That way, the operation is atomic. As far as we're concerned, it's one step, and thus there is no race condition.

Your proposed interface violates this pattern. You may envision the seekability as simply a flag that is turned on or off depending on the filehandle type, but there are different factors that can affect the seekability. These factors can change moment to moment, so a filehandle may be seekable in general, yet still fail to seek at a specific moment. Even with your proposed change, one would still have to check seek's return value to be absolutely sure it worked, which negates the whole point of adding the seekability check.

In short, an is_really_seekable function would invite race conditions, while presenting no descernable gain.