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.