+Perl is now in the process of evolving to follow the setting of
+the DECC$* feature logical names in the interpretation of UNIX pathnames.
+This is still a work in progress.
+
+For handling extended characters, and case sensitivity, as long as
+DECC$POSIX_COMPLIANT_PATHNAMES, DECC$FILENAME_UNIX_REPORT, and
+DECC$FILENAME_UNIX_ONLY are not set, then the older Perl behavior
+for conversions of file specifications from UNIX to VMS is followed,
+except that VMS paths with concealed rooted logical names are now
+translated correctly to UNIX paths.
+
+With those features set, then new routines may handle the translation,
+because some of the rules are different. The presence of ./.../
+in a UNIX path is no longer translated to the VMS [...]. It will
+translate to [.^.^.^.]. To be compatible with what MakeMaker expects,
+if a VMS path can not be translated to a UNIX path when unixify
+is called, it is passed through unchanged. So unixify("[...]") will
+return "[...]".
+
+The handling of extended characters will also be better with the
+newer translation routines. But more work is needed to fully support
+extended file syntax names. In particular, at this writing Pathtools
+can not deal with directories containing some extended characters.
+
+There are several ambiguous cases where a conversion routine can not
+determine if an input filename is in UNIX format or in VMS format,
+since now both VMS UNIX file specifications can have characters in
+them that could be mistaken for syntax delimiters of the other type.
+So some pathnames simply can not be used in a mode that allows either
+type of pathname to be present.
+
+Perl will tend to assume that an ambiguous filename is in UNIX format.
+
+Allowing "." as a version delimiter is simply incompatible with
+determining if a pathname is already VMS format or UNIX with the
+extended file syntax. There is no way to know if "perl-5.8.6" that
+TAR produces is a UNIX "perl-5.8.6" or a VMS "perl-5.8;6" when
+passing it to unixify() or vmsify().
+
+The DECC$FILENAME_UNIX_REPORT or the DECC$FILENAME_UNIX_ONLY logical
+names control how Perl interprets filenames.
+
+The DECC$FILENAME_UNIX_ONLY setting has not been tested at this time.
+Perl uses traditional OpenVMS file specifications internally and in
+the test harness, so this mode may have limited use, or require more
+changes to make usable.
+
+Everything about DECC$FILENAME_UNIX_REPORT should be assumed to apply
+to DECC$FILENAME_UNIX_ONLY mode. The DECC$FILENAME_UNIX_ONLY differs
+in that it expects all filenames passed to the C runtime to be already
+in UNIX format.
+
+Again, currently most of the core Perl modules have not yet been updated
+to understand that VMS is not as limited as it use to be. Fixing that
+is a work in progress.
+
+The logical name DECC$POSIX_COMPLIANT_PATHNAMES is new with the
+RMS Symbolic Link SDK. This version of Perl does not support it being set.
+
+
+Filenames are case-insensitive on VAX, and on ODS-2 formatted
+volumes on ALPHA and I64.
+
+On ODS-5 volumes filenames are case preserved and on newer
+versions of OpenVMS can be optionally case sensitive.
+
+On ALPHA and I64, Perl is in the process of being changed to follow the
+process case sensitivity setting to report if the file system is case
+sensitive.
+
+Perl programs should not assume that VMS is case blind, or that
+filenames will be in lowercase.
+
+Programs should use the File::Spec:case_tolerant setting to determine
+the state, and not the $^O setting.
+
+For consistency, when the above feature is clear and when not
+otherwise overridden by DECC feature logical names, most Perl routines
+return file specifications using lower case letters only,
+regardless of the case used in the arguments passed to them.
+(This is true only when running under VMS; Perl respects the
+case-sensitivity of OSs like Unix.)