The line between syntax and functionality is pretty thin for an assembler.

I've definitely had code that some assemblers accepted and others didn't on the same arch, so even if they could be equally expressive in practice they aren't. Fairly sure that's also true of inline assembly on clang x64, had to change between intel and at&t for something a while ago.

Not really. Intel vs AT&T syntax is about how to generate machine code from mnemonics.

Cooperation with the linker comes with other directives and options. gas has tight cooperation with GNU ld via directives, not instruction syntax. It can actually be set to accept either AT&T or Intel syntax, without losing any support for other features.

The case that comes to mind was emitting a (correct) relocation for one mode and raising an error for the other. That was more likely to be llvm-mc than gas though, so results from on assembler may not apply to all assemblers.

Emitting a relocation with .reloc directive? Definitely sounds like an llvm-as bug.

No, it was an arithmetic expression related to labels. And yes I'd agree that it working in... I want to say intel and not at&t (might be the other way around) is a bug/missing feature. Didn't bother fixing or reporting it at the time though.