efs dis-integration with mule

`insert-file-contents-internal' is expected to use its `codesys' arg. This argument is normally created when `insert-file-contents' tries various ways of determining file coding system, including `insert-file-contents-pre-hook' call. `insert-file-contents-internal' may call filename hanlders obtained by `Ffind_file_name_handler (filename, Qinsert_file_contents)' call. Such handlers are established by remote file access packages like efs. In this case the `handler' call replaces most of processing normally done by `insert-file-contents-internal' itself, including that of `codesys'. But this argument is never passed to `handler' and thus discarded. Handler may even call `insert-file-contents' recursively, which in turn will trigger file coding determining again, with `insert-file-contents-pre-hook' call. So many unnecessary `insert-file-contents-pre-hook' calls may be done on the same file. There may be 2 of them if both efs and dired are loaded. This complicates `insert-file-contents-pre-hook' functions which do some expensive processing. They have to ensure that they work in exactly one of such a calls. In particular, when they check file data, the file should be a local one, perhaps a temporary one previously downloaded by filename handler from efs or like. When they do check *only* file data, this is ok. But if they wish to check file name also, this complicates things. Normally what should be checked is original, user specified file name. So hook functions complicate even more, to check (or even save for future processing) file name in first of its (recursive) calls and check file data in the last one. Is there any guidelines for writing `insert-file-contents-pre-hook' to avoid such complications?