> These projects never take off because hardware designers are inherently conservative and they won't let go of their horrible language (Verilog or SystemVeriog) no matter what.
As a hardware designer whose never been a fan of SystemVerilog but continues to use it I think this is inaccurate. There are two main issues that mean I currently choose SystemVerilog (though would certainly be happy to replace it).
1. Tooling, Verilog or SystemVerilog (at least bits of it) is widely supported across the EDA ecosystem. Any new HDL thus needs to compile down to Verilog to be usable for anything serious. Most do indeed do this but there can be a major issue with mapping the language. Any issues you get in the compiled Verilog need to be mentally mapped back to the initial language. Depending upon the HDL this can be rather hard, especially if there's serious name mangling going on.
2. New HDLs don't seem to optimize for the kinds of issues I have and may make dealing with the issues I do have worse. Most of my career I've been working on CPUs and GPUs. Implementation results matter (so power, max frequency and silicon area) and to hit the targets you want to hit you often need to do some slightly crazy stuff. You also need a very good mental model of how the implemented design (i.e. what gates you get, where they get placed and how they're connected) is produced from the HDL and in turn know how to alter the HDL to get a better result in gates. A typical example is dealing with timing paths, you may need to knock a few gates off a path to meet a frequency goal which requires you to a) map the gates back to HDL constructs so you can see what bit of RTL is causing the issues and b) do some of the slightly crazy stuff, hyper-specific optimisations that rely on a deep understanding of the micro-architecture.
New HDLs often have nice thing like decent type systems and generative capabilities but loose the low-level easy metal mapping of RTL to gates you get with Verilog. I don't find much of my time for instance is spent dealing with Verilog's awful type system (including the time spent dealing with bugs that arise from it). It's frustrating but making it better wouldn't have a transformative effect on my work.
I do spend lots of time mentally mapping gates back to RTL to then try and out work out better ways to write the RTL to improve implementation results. This often comes back to say seeing an input an AND gate is very late, realising you can make a another version of that signal that won't break functional correctness 90% of the time with a fix-up applied to deal with the other 10% of cases in some other less timing critical part of the design (e.g. in a CPU pipeline the fix-up would be causing a reply or killing an instruction further down the pipeline). Due to the mapping issue I brought up in 1. new HDLs often make this harder. Taking a higher level approach to the design can also make such fixes very fiddly or impossible to do without hacking up the design in a major way.
That said my only major experience with a CPU design not using Verilog/SystemVerilog was building a couple of CPUs for my PhD in Bluespec SystemVerilog. I kind of liked the language but ultimately due to 1. and 2. didn't think it really did much for me over SystemVerilog.
If you're building hardware with less tight constraints than yes some of the new HDLs around could work very well for you and yes hardware designers can be very conservative about changing their ways but it simply isn't the case that this is the only thing holding back adoption of new HDLs.
I do need to spend some more time getting to grips with what's now available and up and coming but I can't say I've seen anything, that for my job at least, provides a major jump over SystemVerilog.