> real filesystem APIs have never been tried

How would you approach following problems by representing data as filesystem?

* Represent an array with a million elements.

* Represent data-structures s.a. stack, queue, list, various balanced trees.

* Represent "structs" a.k.a. custom data-types (or even distinguish between a fixed variety of built-in data-types)? Especially how would you enable user to pass structured information to filesystem?

* Allow for custom, more meaningful errors that are sensitive to context. I.e. ENOENT is an awful error if your API is trying to represent eg. an array, then ENOENT may mean "index out of bounds" or that the whole array wasn't found. Not to mention that the error doesn't carry any information necessary to understand and correct it (i.e. if it was an out-of-bounds access, then the necessary information is how long the array is and what index the program was trying to access, if it's a whole missing array, then what path to array was requested etc.)

The above is the bread and butter of any half-decent API. I don't see how you can bend filesystem in such a way that any of these requirements could be satisfied in a way that isn't painful to deal with.

> acme does well here in my experience:

This is nothing to do with acme. It's just always a bad idea to do it. Doesn't matter if you use a text editor, a PDF viewer, a word processor -- anything to do with text, no matter what it is, learn not to scroll. The only time when scrolling is useful is if you are reading text that's long and is meant to be read in order, s.a. a novel or a play. It just so happens that this is the first and most accessible way to navigate text documents that users learn, and they tend to misapply it to problems that have better solutions.

> the typical path:line[:column] address will take you where you expect

In places where this is sometimes useful most other editors offer a way of doing this (eg. in Emacs compilation buffers you need to press RET to go to the location of the error, in VSCode terminal, it's something like Ctrl+Enter... maybe? I don't use that, but saw a tooltip hovering over such info the editor opened by a coworker). I saw this functionality in various GUI terminal emulators too.

> any time a new window pops up, there are sane predictable defaults as to where that window goes

The number of times I want a new window to pop up is very limited (eg. I do expect a new window hosting Magit's command options buffer to pop up, or a completion buffer, if similarly summoned), but I never want to create new windows or move existing windows with the contents that I'm supposed to edit. In my experience, and by looking at programmers learning how to use their editor, this is a bad habit that they need to learn to avoid.

Of course people are different, and there could be unique individuals for whom the exact opposite is true, but if I wanted to give a general advice that would apply to most, I'd insist on never touching window layout after finding the optimal layout for oneself.

> the simple shortcuts of left-clicking a window's handle to expand it

I never want to do this. And if I was working in an environment where this could accidentally happen, I'd work towards removing this functionality. For instance, in Emacs it's possible to resize the window by dragging its margins with a mouse -- and this is part of the reason I always disable trackpad, if I'm working on a laptop, so that I don't accidentally mess things by doing something like that. It never comes as a desirable functionality.