First, people looking to commit implementations to silicon aren't going to wait for the standards process to arrive at an ideal ISA for, e.g., crypto. They're going to add their instructions, spin the glass, and then go back and retrofit their ISA later *IF* it's deemed important enough. This has already happened.
@craigmaloney @satchmoz Then there are people like myself who made their own RISC-V core in Verilog or whatever, and observe the specs are becoming too complicated to follow for FPGA-based designs. I've already announced my intention to fork due to over-bearing complexity. From this frustration came the recognition that small MPUs have very different needs, and proposals are on the table for addressing their needs specifically. Sifive's CLIC core is a good example of what's come from it.
@craigmaloney @satchmoz Personally, my estimation is that this is healthy. I've **NEVER** liked the ITU-style standards-setting process that the RISC-V foundation has adopted. It leads to onerous standards. I find the IETF-model more applicable, where you have at least two compatible yet different implementations in hand before you even are allowed to write the RFC.
As long as communications between groups remains vibrant and healthy, RISC-V has nothing to fear from fragmentation.
Plus, the negative effects of fragmentation seems to be bounded nicely in proportion to the degree that people communicate things on the mailing lists. I don't know to what degree ARM allows for such communications, but with RISC-V at least, it's encouraged.