There were lots of little nooks and crannies in the AmigaDOS 3.1 system software and user experience which were sorely lacking in AROS until recently, and a few that still need to be addressed.
To take an example: There are *still* parts of the console.device and console handler that needs to be added to even match 1.1, never mind later versions of AmigaOS. When I last worked at the console code, a lot of my test cases where example code Commodore released on early Fish disks, written in 1985. A ton of it failed (it's better now, but not yet perfect). Many of them went unimplemented because they weren't used by most apps ported to AROS. But they need to be implemented to handle old AmigaOS apps. Most, anyway.
I don't think there is any intention to freeze things in AROS at the old API, its just a minimum standard by which to judge "improvements" by -- since there's so little chance that the original Amiga OS, MorphOS or OS4 codes would be open sourced for a reference point and compatibility layer in an open source Amiga-like OS.
You're already seeing new stuff, like the 3D support etc. being added beyond 3.1, as well as Zune etc. And to point out the console again since it's the part I'm involved in, my personal goal is at a minimum parity with KingCON, since "everyone" uses it - having just the features of AmigaOS 3.1 would still bring a user experience that leaves a lot to be desired for most Amiga users. Just committed the start of the menu bar the other night, now I just need to start hooking up the actions
(actually, there's more "plumbing" to add first, which goes back to making console.device AmigaOS 1.x compatible...).
Where possible, AROS is also blocking out library offsets used for AmigaOS4 and MorphOS extensions in order to at least keeping the option of supporting them open.
I agree that "defining community standards" isn't going to really help anyone at this time. OS4 and MorphOS have already chosen their paths, and AROS has its own directions to go in.
Defining standards in this situation would pretty much be: Document the current shared behaviors and most important deviations. For example, what MUI controls and options are shared across all? What parts of AREXX works across all (now that Regina works on AROS)? What datatypes can be assumed to be available? Etc.
Creating a compatibility matrix like that would be a highly useful starting point if someone is looking for a project...
Another project that'd be highly useful, would be to start collecting automated unit tests targeting shared functionality, to find corner cases where they behave differently...
