AT&T syntax basically doesn't do anything about conflicts between mnemonic+suffix vs. other mnemonics. Register operands always disambiguate between a mov mnemonic with a q operand-size suffix vs. the movq mnemonic
movq %xmm0, %xmm0, movq %rax, %xmm0, and movq %xmm0, %rax are 3 different opcodes that all use the same mnemonic (movq in both Intel and AT&T syntax).
A suffix is not allowed on the movq mnemonic: Error: invalid instruction suffix for 'movq'. This is normal because there's no possible ambiguity with respect to operand-size. movq always moves 64 bits, so a q suffix would be redundant.
Does this make parsing AT&T harder than parsing Intel syntax? Well before MMX even existed (thus also before x86-64), movl was still the mnemonic for 6 different opcodes (Intel's insn set ref manual entry for mov lists them all, with their numeric opcode):
MOV r/m32,r32
MOV r32,r/m32 (assembler can choose either opcode if both operands are regs)
MOV r32, imm32 (short form)
MOV r/m32, imm32 (with a modr/m, usable for memory operands).
- also
MOV moffs32,EAX and MOV EAX,moffs32, as an optimization (no ModR/M) for storing/loading with a 32-bit absolute address.
And that's not counting mov to/from segment, control, and debug registers. Just like with movq %xmm0, %rax, AT&T syntax has always had to deal with mov %ds, %ax.
Adding a few more forms with different registers to disambiguate is probably not much harder to parse.
Besides that, operand-size suffixes are optional when registers determine the operand-size anyway. mov %rax, %rcx is legal, and a suffix is only needed for moving an immediate to memory. mov $1, (%rsi) is illegal because neither operand implies an operand-size, and there's no suffix to make it explicit.