General hint: If your functions are so long that having to (suppose this was indeed the case) declare/define all your variables at the top becomes a serious annoyance, then chances are that your functions are too long/do too much. Fix that instead.
More general hint: The principle of minimum scope exists for a reason. Declare your variables at the point where they can be initialised, not at some arbitrary point and you make life easier for people trying to understand the lifetime of the variable.
Python brought a unique mixture of functional and imperative syntax and semantics
Various ML dialects had that before Python. The thing Python brought was a poor performance implementation of a language from the C++ school of language design: keep adding features without regard to how they interact and expect programmers to know all of them (if they ever work with anyone else) but only use a subset if they don't want totally unmaintainable code.
Regarding the ISA changes, let me explain further. For the cases you've mentioned we offer a software/hardware compatibility strategy which includes trap-and-emulate, trap-and-patch, and binary translation
For the branch instructions with the reused opcodes, this means that you need to do it up front. This means that things like JVMs and anything else with a JIT requires rewriting. This is where a big part of the cost of the software ecosystem comes from. It also means that disassemblers and debuggers (which are another big investment) also need significant rewriting, rather than just adopting.
Trap and emulate and trap and patch will only work if your MISPr6 processors have a special mode that will trap on any instructions that have had their opcodes reused. In such a mode, trap-and-patch usually won't work, because the compact branch instructions that are intended for use in the patching are in this set.
The new ISA is a lot nicer than classic MIPS, but it's almost as much effort to support in software as RISC V or ARMv8. This is part of the reason why we (with my FreeBSD hat on) have been working closely with Cavium on ARMv8 recently. Existing customers for Cavium's MIPS parts (certain storage and networking vendors) have looked at MIPSr6 and seen that the cost of migrating their code from MIPS III or MIPS64r1 to MIPSr6 is about the same as the cost of migrating to ARMv8. They've also seen the lack of serious investment in LLVM (until very recently, and even then it's far smaller than ARM alone - Apple, Google and ARM are investing an order of magnitude more effort than the MIPS ecosystem) and decided that it's worth working out the cost of an ARMv8 migration.
I mentioned this to Daniel over a year ago, but apparently ImagTec decided that keeping their customers' customers on MIPS wasn't a priority.
There are two problems with this idea. The first is that EMPs, like other EM phenomena, disperse via an inverse square law. Anything high enough to be line-of-site to the ground in most of the USA would need to have an enormous explosive yield (even by nuclear weapon standards). There are some designs that try to channel more energy into the EMP than normal, but they're very complex to build (a good 10-20 years more R&D beyond the Fat Man / Little Boy style bombs).
The second problem is the delivery. Iran does not have a significant ballistic missile capability. Getting something into space above the USA would require launching something in a suborbital trajectory. A very high suborbital trajectory if it were intended to explode that high up. The size of such a rocket would be such that it would be pretty hard to miss on satellite observation. The time in the air would give the US a very long time to formulate a response and destroying it would be relatively easy (remember, the problem with strategic defence shields in the cold war was not shooting down a missile, it was shooting down the large number of real and decoy rockets that the Soviet Union was capable of launching).
I was really surprised to learn recently that Chrome's support for OS X 10.6 is one of the main things blocking Skia from adopting C++11 library features (i.e. the things that make C++ not completely suck as a language). 10.6 has been officially unsupported for over a year and the last security update was a few months before that. It has known security holes (including one from missing bounds checking in DMA requests to the GPU that allows privilege escalation and might be exploitable from WebGL). Keeping these machines on the Internet is not really doing anyone a favour.
It's also a bit surprising that Chrome on 10.6 can't just bundle a copy of libc++.dylib, since none of the system APIs are C++ and the only problem with linking libc++ and libstdc++ is if you use standard library types at library boundaries.
Showing an industrial core is not really possible. MIPSfpga is actually simpler than BERI in a number of ways (though, being written in Verilog, likely to be much harder to understand than something like BERI or Rocket). A real core aimed at anything other than the embedded microcontroller market is going to be impossible to get access to. The kind of things that are substantially different from BERI or Rocket are the high-end out-of-order superscalar chips that no company is going to show you without paying a very big license fee.