Earlier quoted context omitted.
The idea is to own up to this reality, and stop designing instruction sets as if they were meant run directly. x86 in particular has a legacy of simple CPUs that didn't have much of a decoding unit. But now it has gone too far in the other direction: it takes a significant amount of chip surface and energy to decode, making it unsuitable for low power situations. ARM on the other hand is probably lacking in the SIMD…
When I make a long comment, I like to see explanations about what warranted a downvote. So I can learn…
1) The percentage of die used for decoding is actually already quite low. Per Anandtech 2014, it was at 10% for x86 and decreasing:
http://www.anandtech.com/show/8776/arm-challinging-intel-in-...
Since there is a floor to the number of transistors needed for decoding, there might not be a whole lot to gain there.
2) Progress has already been made towards updating instruction sets to reflect what CPUs do quickly, well etc. It started with MMX back in the stone age, and has progressed through a plethora of SIMD and media acceleration instructions.
3) Instruction sets are already not designed as if they were supposed to be run directly. Quite to the contrary, they are abstracted -- the instruction set is the API, and the microoperations are the instructions. Designing them as if they were to run directly would mean exposing the micro-ops, which would require backwards compatibility breaking changes to the CPU each generation when there were changes to the micro ops.
4) The current system already pretty well levels energy consumption between competing ISAs. See: http://www.extremetech.com/extreme/188396-the-final-isa-show...
You're describing something that sounds like a bytecode VM, but in essence, that's what modern processors already are. Unfortunately, x86 (at least 32 bit) assembly is pretty unpleasant as an 'API', but ARM and PowerPC are both pretty good.
As far as pointer tagging, that's something that's probably mostly limited by memory bandwidth (it's not a particularly compute heavy thing to do), so unless the HW support came in the form of a dedicated on-chip cache, it probably wouldn't get you very much ... and then, if you're going to the expense of adding a dedicated on-chip cache, it's probably going to be more effective as a general purpose cache -- if the code is accessing the pointer metadata often, it will be in cache, and therefore accelerated.
Not trying to rain on your parade, I like seeing creative ideas, and I have no idea why people are downvoting you. Have an upvote on me :).
EDIT: Also, ARM has NEON.