Complicates issue #103187 because code in the wrong place is interpreting folder
ordering attributes.

Well, it cannot be in loaders, it would be useless. The goal was to allow 
applications written on top of NetBeans Runtime Container (e.g. without 
openide/loaders) to be able to use Lookups.forPath to read something from 
folders on system file system. This is satisfied.

Re.: "use of Datasystems semantics" - sure. It behaves as simplified 
FolderLookup. Of course that it has to have similar semantics.

I am not sure what exactly you do in issue #103187, maybe we could find a way 
to write the code in different way, share it between multiple usages, etc. 
However the general goal - e.g. ability to interpret SFS as instances without 
openide/loaders - is something I want to keep.

I guess I don't follow what the purpose of not using openide/loaders is. If you
want the semantics of InstanceDataObject, you should simply use the API module
which provides that semantics. Why not?

For issue #103187 I expect to need a common API in openide/fs which could be
used in RIF.

Re. "purpose": once upon a time there used to be a discussion. Was it right to 
use openide/loaders for settings management or not? Was not it too heavyweight 
to empower all the loader stuff to just read a menu definition? Well, yes it 
was. The issue 98426 creates an alternative. #1 it is possible to read 
declarative registration with Lookups.forPath, #2 one can use .instance syntax 
on SFS without relying on loaders at all. Of course, the advanced tricks of 
openide/loaders - e.g. .settings files, or InstanceCookie in any kind of 
object, etc. are not supported. But that does not matter from the point of 
view of an extension point provider: "If you want to register something for 
me, put .instance files into X/Y/Z folder on system file system. If you want 
to register something more complex, then depend on core/settings, follow their 
contract and use .settings files, convertors, or your own loaders with 
InstanceCookie. I do not care, I use single common API that can read X/Y/Z for 
me."

Re. "Single API in RIF" -
#1 it is not very good to create an API just for one client. 
#2 maybe you do not need this API to be public, core/startup and openide/fs 
are loaded by the same classloader anyway or can have impl dependency.
#3 recently you moved layer parsing to openide/fs, maybe the RIF could be 
implemented in openide/fs as well, then there would be no need for an API

I don't understand how using Lookups.forPath will allow you to read more complex
settings with *.settings etc. FolderLookup would read them, but AFAICT L.fP will
not.

RIF could equally well be in openide/fs; no strong opinion. But the API for
folder ordering I mentioned is needed from other places, not just RIF. See wiki
for the list.

When core/settings is installed, L.fP reads the SFS content using 
FolderLookup.

Ah, I missed that.