Is there an issue with `add-symbol-file`ing a different architecture

Hello,

I am trying to sync symbols from a decompiler into GDB. This is
"standardly" done by crafting a small ELF which essentially just
contains a symtab with the decompiled symbols and
`add-symbol-file`-ing it into GDB. I'm working on a small library
for crafting these ELFs https://github.com/pwndbg/niche-elf and am
encountering a few weird edge cases so I figured I'd ask here about
it.

An ELF file that it crafted like this is architecture-agnostic
except for two things. The ELFCLASS which describes whether the
ELF file itself will be 32 bit or 64 bit. And the e_machine header
field, which describes which CPU architecute the ELF file is for
(which also has 32 bit and 64 bit variants).

Currently, everyone that does this type of syncing does not match
the ELFCLASS, nor the e_machine header with the debugee target.
I.e. the elf class is always ELFCLASS64, and the e_machine is the
same one the host uses, which is x86_64 in most cases.

This seems to mostly work even when debugging other architectures,
but I did some playing around and when setting the e_machine header
to some more obscure architectures, stuff starts breaking.

So here are my questions:

1. Is it safe to always use ELFCLASS64, even for 32-bit architectures?
2. Is it safe to use a 64-bit e_machine for 32-bit targets?
3. Is it always safe to use the host's e_machine?
4. Is it always safe to use x86_64 as the e_machine?

What does GDB actually look at here, when loading a symbol file into a
debugging session?

Best regards,
k4lizen

P.S. I asked about this in the binutils mailing list, but didn't get
any response regarding this.