Can you maybe possibly explain what do you exactly mean by “forwards and backwards compatible”?
If you ask whether an older version of Krita will be able to read a resource folder written to by a newer Krita, then the answer is “mostly, yes”. If you ask whether a newer Krita will be able to read a resource folder written to by an older Krita, the answer is “mostly yes”. There are some limitations: for example in older versions of Krita there was a brush preset engine called “Dyna engine”; all presets using that engine can be only read by older versions of Krita. However the newer Krita doesn’t remove it or anything, just not use it. There are a few new features in brush engines that if the preset uses them, it will look differently in the newer version of Krita (that has those features) than in an older version of Krita (which still should be able to read it though). We do try to make sure that old resources are read the same way from version to version.
Note that there are people using multiple appimages on Linux or multiple portable versions on Windows already. Those are usually similar versions though. I do have Krita 3.3.3. appimage on my Linux (current version: 4.3.0) and it can read by Krita 5.0 (future version, not released yet, with resource system rewritten, more details later) read and written-to folder just fine.
Another note: we are in the middle of resource rewrite. There will be some differences in how the resource folder is used. Things that might not be compatible between versions before and after are (1) tags (they are imported, but all newly created tags will be, at least with the current design, only accessed in the new version), (2) information which presets are deleted by the user (since in Krita the user cannot delete anything, just hide it), (3) tasksets (technical reason; they are moved from one folder to another, so it’s possible to use older tasksets in Krita 5.0, but after one opening they won’t be accessible for older Kritas).
Also another note, from Krita’s interface users cannot really break much. Any resource that user “deletes” is just blacklisted, not actually deleted.
I don’t think it’s possible now to use several resources folder. In the new version it will be possible to define the resource folder in settings. In any case, Krita will need to have one “main” resource folder to keep its “what is deleted” information in (right now it could be possible to have it in several place, but the next version will have a database, and that’d be not good to have multiple of them).
I am going to implement Resource Manager that will hopefully solve the issues users have that make them fiddle with resource folder. I’m not sure how successful I’ll be at it, though. There are some users confused a lot with for example our nomeclature - “brushes” vs. “paintoppresets” especially.