Your intended microarchitecture matters: If you plan to use register renaming, you want to avoid instructions with large numbers of destination registers and favor conditional move instructions over conditional instructions.
(I also don’t know which processor added conditional move – but there’s a good chance it was a processor with register renaming.)

If you’re more focused on energy efficiency, you might choose more complex instructions requiring greater logic depth – but that’s going to hurt your high frequency implementations.

How long you’re going to have to live with your design choices. If you’re commercially successful, you’ll be living with them for 20-30 years so decisions which make a huge amount of sense for today’s microarchitecture may be things you regret in 15 years time. So you’ve got to anticipate all the various scaling trends (Moore’s law, memory wall, power wall, dark silicon, …) but also produce a design that you can make well today. You’ve also got to leave room to add new instructions in the future.

Do you want to define subsets of your architecture for use in cost/area-constrained niches like microcontrollers? (Microcontrollers are often implemented on older processes like 180nm or 130nm instead of the 45nm or 32nm used for high end cores so, while Moore’s law applies, they’re behind the curve.)
And if you do aim to service multiple niches, then you have to consider a wider range of workloads – embedded code is very different from running a web browser.

Do you want to support high performance computing? How are you going to support the massive parallelism and energy efficiency required for exascale machines? With 1,000,000 or more processors, reliability is an issue – what will you handle in software and what in hardware? Do you handle it in user-level code or only at the OS layer?

And then you have to produce compilers – some degree of completeness and regularity are a good idea. In a regular architecture you can exploit these by first generating a direct version of the code (using simple instructions) and then applying a series of peepholes to replace them with more complex compound instructions. If the ISA lacked the simple instructions, you would have to leap straight for the complex instructions. (I’m especially thinking of vectorization here – you have a complex transformation with many side-conditions which prevent it from being applied so you want to start by targeting a simple ISA, and then be able to apply a series of transformations to improve on it. Too many optimality islands will be hard to target.)

Do you even have the workloads you need to produce the traces? SPEC is hopelessly unrepresentative of real programs. JITs are changing rapidly, runtime code generation seems to be making a comeback. Languages are becoming more dynamic (more branches, more indirect branches) – but will that trend reverse as designers accept that Moore’s law is ending (if it is) and programmers have to take an ax to today’s bloatware? In the time it takes to launch a new processor, get compilers, OSes, etc. fully up to speed, get enough design wins to reach high volume, etc. all the key parts of a web browser will be completely rewritten. So just as you have to anticipate the hardware trends, you have to predict some of the software trends in the absence of actual workloads.

Scott Mahlke has also done a raft of related work.

(2) Galois multiplication is not nearly as common as integer multiplication. If the divisibility property is important, then you should work in a large prime close to 2^n. However, the number-theoretic characterization of division is usually more important than its algebraic properties.

By the way, the AES-NI instruction set does allow faster multiplication over a Galois field.

Modern OOO processors tend to make pretty fast and loose with the information exposed in an ISA, caching it, rewriting it into microcode, etc. Thus a highly specialised instruction stands at least some chance of becoming obsolete over time as the processor implementation evolves, whereas compactness doesn’t seem likely to ever become undesirable so long as caches are still a thing.

One thing you didn’t list that I would add is MIPS’ two versions of integer arithmetic instructions, one which TRAP on integer overflow, one which set the flag register: very useful for implementing sane integer semantic like Ada does.