Does that mean it's not the game?
It could easily be a reflection of Frontier treating AMD differently, or with lesser consideration, possibly because Elite: Dangerous was originally a TWIMTBP title, possibly because AMD has a much smaller market share.
The most major issues (Orange Sidewinder crashes) are resolvable simply by disabling native double precision, which should probably have been disabled by Frontier on every post Hawaii card since it can't offer a performance advantage on any newer consumer part because they all have radically inferior FP64 ratios (most everything after has been 1/16). Likewise, the game doesn't even know there are cards newer than the R9 200 series (which launched in 2013) and inexplicably uses different terrain shaders for AMD and NVIDIA, despite the NVIDIA shaders being smaller and working just as well on AMD GPUs if you rename them.
The remaining issues--the blue overlay and the much older lack of line aliasing--can't currently be fixed in native D3D11. The line AA issue can't be fixed at all and has been around since the launch of the 6000 series. The overlay (which appears to be a shader issue) started with the May preview drivers (same branch as 22.5.2 and later) and can only be resolved via DXVK.
Just go on the AMD forum and look at all the issues being reported (and ignored) for games being broken by the new drivers.
Any major change to driver branches introduces a pile of new bugs; just look at the known issues list for any GPU driver package (AMD, NVIDIA, or otherwise).
This doesn't imply any more corners are being cut than usual, and the usual is a huge number of cut corners and other optimizations, because strictly following the rules and matching any reference renderer would result in a categorically non-competitive product. AMD and NVIDIA can get 97-99% of the way there at the speeds we see, or get 100% compliance at a tenth of the performance.
I'm not even sure that the newer driver branch is less compliant...I'd need to see comparisons in output vs. those reference renderers. It's entirely possible, even likely, that the newer driver branch is, overall, more correct than the former, but that the game still doesn't like it, or that the driver hasn't received app specific patches for niche games yet.
Planet/terrain generation relies very heavily on the GPU via compute shaders, using them to a much larger extent than most games.
Instead of the details of the entire planet's surface being stored in a database somewhere and being sent over the network every time someone visits it, the game feeds the planet's "seed" into the generator and the GPU does all the work to calculate the terrain. Something is going wrong during that generation with the newer AMD's drivers (either it's returning values out of range or perhaps the game is using some sort of checksum to ensure all players see the same terrain, and there are inconsistencies) causing the game to throw Orange Sidewinders.
See above. This issue is, as far as I can tell, completely resolved, with no performance hit (and in D3D11), by setting PermitNativeDoubles="false" in AppConfig.xml. Which should be the default if the game detects any AMD GPU after Hawaii (because even an RX 6950 XT barely has more FP64 performance than ten year old AMD GPUs).