Created attachment 127863 [details]
Proposed changes - initial version

Currently we have FileObject.revert(), which can discard user changes for existing files on writable layer of MFS among other things. But if the files does not exist at all, there's no FileObject to call revert() on.
In addition, it may be useful to be able to read attributes and contents of the deleted file (or the original version of the file) in order to decide whether the file should be revert()ed or not. The current FS API does not allow such inspection.

I propose to add a 'development' stability pseudo API - an additional FileObject attribute "revealEntries" on FileObjects representing folders. The value of such attribute would be typed Collection<? extends FileObject>. If the FS does not support the feature (i.e. not MultiFileSystem, or MultiFileSystem without writable layer - effectively unable to revert() changes), the returned value would be null.

In addition, the returned FileObjects would implement Callable<FileObject> interface - 
public FileObject call(). If called, the changes for the file will be reverted on the writable layer, and the revived MultiFileObject will be returned to the caller (if exists).

Those FileObjects should be guarded against DataObject creation, as there could be 2 DataObjects for the same path, which would do no good - I propose that the returned FileObjects should be isValid() == false from the start.
Next, references to the fileObject.getParent() or getChildren() should not reveal lower layers of the MultiFileSystem; so I propose that the returned FileObjects would be formally part of the MultiFileSytem, under a proper parent, and with appropriate MFS children.

As the information for deleted/original content is represented as FileObject, the caller may inspect any attribute, content or flags; this would be hard to achive with other API type - only a subset of information could be exposed.

See the attached patch against openide.filesystems for proposed API/implementation/tests.