Porting complex applications (especially those written in C) from x86 to ARM can be pretty non-trivial.
I can't speak to the GIMP code in particular, but I've done several x86->ARM source ports of other complex software, and each time there are things which work on x86 and don't work on ARM, resulting in nasty crashes, or worse.
We live in an age where combining music, software, and signal processing can let you do some amazing things. I can imagine a high-fidelity simulation of this instrument's timbre before it's ever built, by using the mechanical CAD model to produce an acoustic model, and then modeling the response of the wood to an incident acoustic wave.
The whole world of software ports basically boils down to "anything is possible, given enough memory, pixels, and time". The actual process of porting anything is sometimes incredibly tedious (e.g. "scour the entire source code for unaligned memory accesses, and manually rewrite all of them"), but also gives a chance to do some very clever things (like, "use the piezo speaker to beep out the address of a fault, because nothing else works on the device after a crash").
What made me do it was 1) the satisfaction I got from seeing my work produce something which, at first glance, shouldn't exist (Quake... on an MP3 player?), all while 2) learning deeply about software close to the bare metal, which is fairly hard to do early in one's career. There's of course also the factor of having lots of free time - I did my port when I was still a student with not very many responsibilities, so I could afford to spend entire evenings and weekends poring through mountains of C code. Nowadays, not so much...
The whole world of software ports basically boils down to "anything is possible, given enough memory, pixels, and time". The actual process of porting anything is sometimes incredibly tedious (e.g. "scour the entire source code for unaligned memory accesses, and manually rewrite all of them"), but also gives a chance to do some very clever things (like, "use the piezo speaker to beep out the address of a fault, because nothing else works on the device after a crash").
What made me do it was 1) the satisfaction I got from seeing my work produce something which, at first glance, shouldn't exist (Quake... on an MP3 player?), all while 2) learning deeply about software close to the bare metal, which is fairly hard to do early in one's career. There's of course also the factor of having lots of free time - I did my port when I was still a student with not very many responsibilities, so I could afford to spend entire evenings and weekends poring through mountains of C code. Nowadays, not so much...
There is no way this could work. The EDA tool (e.g. KiCAD) is only the first step of the fabrication process - you generate Gerbers from your KiCAD board layout, which are a highly standardized format that can be viewed in a variety of independent pieces of software. There are also multiple stages of design validation - both in the design phase, and then in the physical phase of actually inspecting your fabricated boards. The chances of any "malicious" circuitry slipping in are next to nil.
I can't speak to the GIMP code in particular, but I've done several x86->ARM source ports of other complex software, and each time there are things which work on x86 and don't work on ARM, resulting in nasty crashes, or worse.
See here for one of those (not AArch64, but ARM nonetheless): https://news.ycombinator.com/item?id=22176285