I agree with Zoffix that this seems to be fine as is. Generally speaking, IO operations that logically require an existing path will return a Failure if the path does not in fact exist:
Slurp its content? Failure. Rename/move/copy it? Failure. Check its size? Failure. Check if it is of type "directory? Failure. Check if it is of type "file"? Failure. Whereas `.e`, i.e. checking if a path exists, is by necessity *not* an operation that assumes an existing path. The only thing that might be debatable, is whether `.f` should mean: a) Check if it is of type "file". b) Check if it exists, and if so, if is of type "file". The current behavior (a) seems more natural and useful to me though. Perl 5 does (a) as well, in the sense that it too distinguishes "failure" from "no" in the return value: - "yes, it is of type 'file'": a defined truthy value - "no, it is not of type 'file'": a defined falsy value - "failure, it does not exist so its type can not be checked": `undef` Perl 6 merely improves on that by promoting the failure condition from `undef` to `Failure`, which both carries more information and provides more safety by default. To the extent that you're basing your expectations on the fact that a Perl 5 `undef` can be used in ways that a Perl 6 `Failure` cannot (without blowing up), well, that's just a matter of having to unlearn Perl 5 (or other programming languages) while learning Perl 6... :)
