[Oberon] NativeOberon's FileName limitations - HOW2 extend?

[eas lab]

Linux : X11 is a monster, but LNO [121104] runs in a FrameBuffer nicely;
 also under 64bit.
Why would you NEED LNO ?
1. to have multiple files visible together on the same screen;
2. with powerfull mouse-chording ability;
PublicDomain wily [needs X11], copied from ETHO, is even better, except lacks
3. ETHO's coloring capability: to give an extra dimension to
  complex relationships between texts, possibly in multiple files.

Mildly complex tasks, soon need 4, 5, 6 ...TextFrames viewable-together.
Since screen-area is the limiting factor, M$'s wastefull <staggered frames>,
copied by Aos, is NOT acceptable.  The paper-book, where each of hundreds
of pages "automatically line-up", is a magical concept!

The big problem/weakness of LNO: not being able to immediately read/write
to files anywhere in the file-tree, can be reduced by:
1. use a convenient file-navigator, like mc, which allows to
2. <push a button> at the reqired-file, which stores its /PATH/Name to a
  fixed location, which
3. is accessed by LNO to mount the file-to-be-accessed by LNO.

Right now, while composing this text, via USBstik:Linux:TinyCore46:LNO
I want to access some Oberon:V4 files on the M$-partition.
I failed: apparently LNO can't mount FATFS, like LEO can.
It shouldn't be difficult to extend the capability?

But read/write to V4 files in LinuxFS, is OK via:
FileSystem.Mount V4 LinuxFS /mnt/sdb2/CRG/ETHO/V4dirTree/usr/local/oberon/Text/~

The 4-string command/M.P had the last/long string stored in the known location;
so "V4" is my chosen name and string1, string3 are in the <Tools Text>;
and the user need only add his chosen name to make the 4-string command.
Then System.Directory ^  V4:*  lists the directory contents; giving immediate
 access to the 96 files:-----------
V4:.
V4:..
V4:Analyzer.Tool
V4:AsciiCoder.Tool
V4:Backup.Tool
V4:Balloon.Text
V4:BalloonIdx.hlp
...
V4:Find.Tool

V4:Welcome.Text
V4:Xref.Tool

96 files  ----------------
LNO can access all: Aos, *nix, FATFS and presumably V4 formats.
The PROBLEM remains, to access eg. "tmp:mc-root", where "mc-root"
  is not a valid <FileName>.
AFAIR <Linux ETH Oberon> was able to access such filenames by quoting?
Can we extend LNO, perhaps based on LEO?

== Chris Glur.

PS. The fact that ETHO's System.Directory output is not available:
 ordered by recentcy, is a serious deficiency: not acknowledging that
<the stack and tree> are central to cognition & thus computing  ?