The general rule of thumb is to have the API behave as if no wrapping is occurring. The outermost layer should still adhere to the documented API requirements, so both flush and close should cascade (flush says it flushes the "buffers" plural; all user mode buffers should be flushed, no matter the layer), closing the outer layer without closing the inner makes it non-intuitive as to *how* you close the inner layers at all.

So the answers are:

1. flush all layers when told to flush
2. close all layers when told to close (exception for when you accept a fd, you can take a closefd argument and avoid closing the fd itself, but all Python layers should be closed)
3. N/A (close cascades)
4. No.
5. Non-blocking I/O doesn't seem to have a completely consistent story, but from the existing classes, I'm guessing outer layers should try to write to the underlying stream when told to do so, and raise BlockingIOError if they'd would block. The close story should be roughly the same; try to flush, raise BlockingIOError if it would block, then close (which shouldn't do much since the buffers are flushed).
6. No.

#5 is weird, and we could probably use a more coherent story for how non-blocking I/O should be done (asyncio provides one story, selectors another, and the io module seems to sort of gloss over the design strategy for non-blocking I/O).

You can derive all but #5 from how the built-in open behaves; it returns different types (FileIO, Buffered*, TextIOWrapper), but whatever it returns, you don't need to pay attention to the layered aspect if you don't want to (most don't). flush works as expected (no flushing each layer independently), close works as expected (no leaked file handles from only closing the outer layer), using it with a with statement is identical to explicitly calling close with a try/finally block.