It doesn’t really matter. Both are available and both will compile the same code, with the exception of a few things that make use of extensions of one particular compiler. The only difference is that we use clang by default while most others default to gcc. They’re fully binary compatible, so this is not a problem even if you link a library built with one compiler to a binary built with the other.
Not sure what you mean - you can build appimages on OM the same way you would on anything else, we don’t do anything special there (nor do we particularly encourage it, they can be useful in particular for some non-free code, but we prefer native packages)
What makes you think xfs is “iffy”? The only thing that’s potentially iffy there is that grub’s support for it has traditionally been less than perfect, so you may want to put /boot on ext4 or btrfs. There’s certainly no problem with xfs. Our testing usually shows ext4 outperforming it though.
I wish I could remember where I saw it - something about after compiling something not in the repo consider turning it into an appimage {shrug}. I’ll track it down eventually.
It was over in the release notes for both Rome and Rock (under filesystems):
On my only hardware computer I use xfs for all my operating systems which are all OMLx of differing branches. I have a data partion that is ext4 but I would not have any problem moving that data to an xfs partition but everything is working so I have not bothered with that. In my experience for multi-booting with OMLx the best choices are ext4 and xfs and you can combine the 2. btrfs and f2fs OMLx OS’s don’t recognize other OS partitions, at least in my experience.
In test VM’s mostly in VBox I do use btrfs and f2fs mostly just so those do get some testing.
