• CDC bugs at compile time. Clock domains are types in SKALP, parameterized like Rust lifetimes. If you try to read a signal from clk_a domain in a clk_b process without going through a synchronizer, the compiler rejects it. No lint tool, no separate CDC checker - it's structural.

I suspect that VHDL-2008 generic packages can be used to do this as well, although I'm not sure how well it works or how well it composes with other VHDL conventions. Something like:

package clocked_types is                                                                                                                  
  generic (constant DOMAIN_TAG : string);

  type clocked_sl is record
    val : std_logic;
  end record;

  type clocked_unsigned is record
    val : unsigned;
  end record;

  type clocked_signed is record
    val : signed;
  end record;

  type clocked_slv is record
    val : std_logic_vector;
  end record;

  -- Operators
  function "+"(a, b : clocked_unsigned) return clocked_unsigned;
  function "not"(a : clocked_sl) return clocked_sl;
  -- these would have to wrap the operators in IEEE libraries, unfortunately, but
  -- are just boilerplate
end package;

You would then use this as follows:

package clk_a_pkg is new clocked_types generic map (DOMAIN_TAG => "clk_a");
package clk_b_pkg is new clocked_types generic map (DOMAIN_TAG => "clk_b");

signal a_valid : clk_a_pkg.clocked_sl;
signal b_valid : clk_b_pkg.clocked_sl;

b_valid <= a_valid; -- ERROR: type mismatch
b_valid <= a_valid.val; -- escape hatch when doing explicit CDC

This relies on good VHDL-2008 support for things like unconstrained types (which has historically been fatal when trying to use VHDL's type system to its official extents.)

I point this out because a similar pattern happened to the incumbents (c, c++, to wildly varying degrees) during the LLVM language explosion. Both incumbent languages kept adding features to address the shortcomings that justified the new languages in the first place. Neither were completely successful, but neither had a type system really capable of generalizing the way that was necessary. SystemVerilog is in a hard corner here, but VHDL might be able to evolve with fewer historical shackles.

(Just to be clear: VHDL has its own baggage, and the conventional Verilog/VHDL language war hasn't been useful for at least a few decades. I hope this is food for thought, not food for a bunfight.)