I wasn't trying to FUD, I'm a huge supporter of AROS on both 68k and x86.
I suppose I was a bit too harsh in saying "not remotely binary compatible", but having just a few cli commands is far from loading up a real application. Those haven't even touched the UI yet.
There is a lot in AROS that wasn't in OS3.1, for example the HIDD, that are required to be in the ROM. I'm not sure what the plan is, to support HIDD in ROM or have an OS3.1-like hardware banging arrangement, but shrinking it all down to 512k with HIDD seems unlikely.
I don't think the HIDD adds all that much - the code to bang the hardware needs to go somewhere. The HIDDs just adds a tiny bit of indirection. Some work might be needed to allow excluding generic versions of the code paths, though, and I'm sure there'll be other optimization work along similar lines to selectively reduce the code generated.
Also it doesn't necessarily all need to fit in 512k. First of all most Amigas can take 1MB kickstarts if you're first going to replace the ROM (and for Toni's needs this works fine for most uses anyway, as UAE handles 1MB ROMs). Secondly for most purposes it only needs to bootstrap and load the rest from a device, though of course this wouldn't be great for Minimig's or classics with just a floppy (but how many would leave their classic unexpanded and still want to use AROS on it?) and not ideal for UAE either.
The current x86 kickstart is 1.5MB, so 1MB doesn't seem too impossible, worst case by pushing various AROS-specific functionality to on disk modules. 512k might be a stretch. I might agree with you that if specific software has problems with that, then creating a custom 1.3 compatible kickstart might be worthwhile but I don't think you'll need to split 3.1 vs. "full AROS" as I don't think much software that works on 3.1 will make assumptions that can't be accommodated.
In terms of compatibility, there are some bits I know will cause minor problems (AmigaOS ConClip for example won't work with AROS console handler, and uses undocumented library calls, - but it'll be easy enough to prevent it from doing any damage by stubbing them out for cases where it's included on boot floppies etc.). I'm sure there are many others that I'm not aware of, so of course it'll be a lot of work, but since AROS is by no means set in stone and everything is set up for quite a bit of API breakage in AROS for 1.0 anyway, I think it'll get fixed.
The nice things about having the m68k port now is that we can start using real AmigaOS apps as test cases - that alone will probably make things progress a lot faster. For my console changes for example I wasted a lot of time cleaning up old console example code to get it to compile under AROS to compare with how it behaved under UAE, while with the m68k port I can hopefully soon run this code directly, side by side with two different UAE configs.