they should not be a reason for fdopen. The main goal why I wanted to keep fdopen is in cases were parrot is embedded and the bytecode gets called with an external FILE * pointer. This might be for example yyin. But is it needed that this must be an opcode or can it be a method of some layer-object.
fdopen does make sense, especially in the UNIX world as it is common to have a file descriptor that you want to open a standard stream on. It could be a known constant fd, or one passed by some other API, another processes, etc.. More obscure cases include execing() yourself without closing any files, which is possible, but probably not in Parrot since Parrot would just reload bytecode; no need to exec().
But I don't know whether it makes sense as an opcode since it is platform dependant.
I am glad you are having a go at it, I've been avoiding the issue. :)
-Melvin