I can see RISC-V gradually taking over, since it now has a foot in the door. But it’ll take a long time and depends on third party development.
One thing that we will have to see about is whether the extension model they have now actually holds in the future e.g. will we see a high performance fork of RISCV in the future, or simply (say) a chinese-only company who don't particularly care using parts of the instruction encoding space for their own purposes.
If it does, would it be a pain to program for (see Cell)?
(1) Unfortunately compressed instructions were included in the Unix profile which causes a lot of pain and makes it mostly impossible to do any partial predecode at I$ fill time. Ironically Arm64 wised up and removed the Thumb variants. (Preempting the code density crowd: there are other ways to deal with this). EDIT: Pain includes dealing with instructions that crosses cacheline or even page boundaries (hello double fault), but worse, not being able to tell what might be an instruction in the I$. It was a sad day when RISC-V with essentially no input from the higher-end concerns decided to force it on us.
You can also use a QEMU or Valgrind-like thing to JIT the C away.
Or you can do what modern x86 does and annotate your cache lines the first time they are actually decoded instead of at cache fill time. That's just a little slower for cold code but the same for hot code. Having the C extension keeps 40% more of your code hot for any given cache size.
There might be some implementation point at which Aarch64 wins by having bigger but fixed length code, but it's not at the low end and I don't think it's at the very high end either.
More compact code takes pressure off icache size and refill rates, and transfer rates from icache to fetch buffer. And ROM size in embedded, sich as on FPGA.
As more designs get produced, there will be more and more pressure on the chip designers to stick to the published specifications, instead of going their own way. Why? Because everyone will want to just use the existing toolchains (GCC, LLVM, etc.) and not have to support proprietary extensions. It helps that the specs themselves are easily available.
The implementations that exist now are not at the leading edge of performance, but they are more than good enough for many applications. This will improve over time.
One of the best features of the ISA is the design for extensions... meaning that extensions were planned from the very beginning. Unlike other architectures, where often the ISA is designed to be "complete", and adding extensions inevitably becomes difficult, expensive (cost or run-time performance, or both), or complex (which slows adoption).
In what market segment?
Will RISC-V win a substantial market shares in embedded / micro- controller usage? Very likely. It is sort of started happening already.
Will RISC-V wins over a substantial market in current x86-64 and ARMv8 segment. Highly Unlikely. I have seen zero argument or proposition that even make sense for this to happen. Other than people want it or certain country want it for whatever ideology reason.
Or you mean designing an ISA from scratch? Which is precisely what ARM have done to ARMv8. And further refined in ARMv9.
There are A32 features that A64 carries over which no one else in the 35 years of RISC ISA design since 1985 has seen fit to copy -- the optional shift/rotate of one ALU operand being the obvious one. Would they really have done that if it was a clean sheet design? If it's so great, why hasn't anyone else done it?
Also no other clean sheet ISA designed for high performance since 1990 (it's a short list: DEC Alpha, Intel Itanium, RISC-V) has included condition codes. Even POWER acknowledges that a single condition code register is a bad idea and has eight of them instead (the others just use integer registers to hold long-lived conditions).
Dreamers gotta dream I suppose.
Moreover, they have no motivation to introduce too many non standard/proprietary extensions as it would require them to add support for these new instructions in mainstream compilers, while they could - with standard extensions - take advantage of the work already done for standard extensions.
Today, a major difficulty a newcomer to the industry faces is that they have 2 options:
1 - Taking an existing ISA and paying a license fee, but benefiting from the work already done on the compiler side.
or
2 - Building their own new ISA for free, but having to do all the work on the compiler side by themselves from scratch.
With RISC-V this problem does not exist anymore which opens the door to newcomers.
There is no way today to build competitive opensource hardware, and RISC-V is not about providing opensource hardware. With RISC-V (or any other ISA) we remain mainly dependent on the manufacturer who implement whatever they want within your processor. I think you are expecting too much from RISC-V, it's not about winning a war against manufacturers, it's about providing a royalty-free high-performance standard ISA which makes it easier for newcomers to enter the market.
RISC-V is built around the idea that manufacturers can make their own non-standard extensions and benefit from existing work.
The first silicon with the final ISA design (or at least RV32IMAC) was the FE310 which shipped on the HiFive1 in December 2016, less than five years ago.
It takes up to two years to go from RTL working in verilator or on an FPGA to manufactured chips on boards in shops.
RISC-V is all over the place in deep embedded. Samsung announced that their 2020 high end phones have RISC-V cores controlling the camera and also the 5G radio. Qualcomm is using RISC-V in their 5G. The very popular ESP32 series of WIFI/BT chips is switching to RISC-V, with the last three (?) models being either partially or fully RISC-V instead of Xtensa.
The last several months have seen announcements of startups who have chip designers from Intel, AMD, and Apple's M1 team and who are now working on *lake/Zen/M1-class RISC-V designs. Those will of course take maybe three or four years to appear on the market, but there is zero reason to think they won't be technically successful.