Since your post was long, I'll try to keep my response simple.

128 cores with small caches one a chip is a pipe-dream. Yes, the logical core of the Itanium is small, but it's not that small.

Take for example, Madison, the first "real" Itanium worth talking about, because it had a respectable amount of cache to keep the processor fed. At 374mm^2 on a 0.13 micron process, it's a big one, and at best, you'll fit two of these boys on a 90nm process (Montecito), four on a 65nm process (Tukwila), and eight on a 45nm process, and sixteen on a 32nm process.

Even if you nix some more cache, the best you can get is around 16/32 cores using your cutting-edge 45nm/32nm processes (this is ignoring the overhead of cache coherency support, which gets more complex as you add more cores). In addition, cutting the cache has a LARGE detrimental effect on performance with EPIC, because the processor takes every branch until the test is evaluated (see my post above). You're just not going to get 128 cores on a chip with EPIC.

As for getting rid of vectors...vectorization is a necessity today! Vectorization cuts-down on the instruction decode overhead of having individual instructions, placing the burden on software. Sure, it sucks for many tasks, but the reality is that the costs of adding it are less than the costs of adding another ALU/FPU and another dispatch pipe to keep it fed.

And I wouldn't decrease the number of instructions in a bundle - the number of instructions within a bundle defines the upper-bound of IPC for Itanium. Changing this would also mean you'd need a new set of optimizing compilers.