a meditation on the direction of IO::Path::*

thoughts on IO::Path

Okay, the class system for IO::Path looks something like this at present in the spec:
class IO::Path is IO::Dir is IO::File;  #knows the OS it should use, default current OS
class IO::Dir is IO::Path::Base;
class IO::File is IO::Path::Base;
class IO::Path::Base does IO::FileTestable;
class IO::POSIX;  #speculative

The problem is all of the Unix/POSIX specific functions, which should not be included unless
they run on the OS.  And manipulating paths for Foreign OSes, which would look like normal IO::Paths.

So what if we instead create Dir and File subclasses for each specific class of OSes?  It should look
something like this:

class IO::Path -> hand-off to other classes
role IO::Dir;
role IO::File;
class IO::Path::Base does IO::FileTestable;
role IO::POSIX;
class IO::Dir::Unix does IO::Dir does IO::POSIX is IO::Path::Base
class IO::File::Unix does IO::File does IO::POSIX is IO::Path::Base
class IO::Path::Unix is IO::Dir::Unix is IO::File::Unix does IO::POSIX;
class IO::Dir::Win32 does IO::Dir is IO::Path::Base
class IO::File::Win32 does IO::File is IO::Path::Base
class IO::Path::Win32 is IO::Dir::Win32 is IO::File::Win32;
#...etc, for each supported OS


IO::Path::Base would be have method that every class used, like, .parent, .is-absolute, etc, as well
as the filestests
IO::Dir would contain the basic functions like .contents, and .child
IO::File would have functions like .open
IO::*::OSname would contain the correct File::Spec subclass for the roles to work,
  in addition to POSIXy things if applicable
These are the things ultimately created
IO::File::OStype would be for files, IO::Dir::OStype for directories -- these would be automatically
  created by dir, etc, by statting files as it goes
IO::Path::OStype would be for objects where we don't know what it is -- mainly files that don't exist
  and can't be statted.

This means that we always try to stat, even on paths that don't exist.  Because manipulating non-existent
paths for use on another computer is a perfectly possible activity.

Okay, so then what happens if we take out the File/Dir distinction?  Each object would have .contents and
  .open (though IO::Path::Base), even though they both don't apply.  But our class system looks simpler.
class IO::Path -> default IO::Path::$*OS
class IO::Path::Base does IO::FileTestable;  # (and contains everything IO::Dir and IO::File had above)
role IO::POSIX;
class IO::Path::Unix does IO::POSIX is IO::Path::Base
class IO::Path::Win32 is IO::Path::Base
#...etc, for each supported OS

I'd just like to know what the advantage to having different classes whether something is a File or a Dir?
It seems harder than calling .d if I need it.  But there might be an advantage I'm not seeing.