Why is xbar_latency_e an enum?

[FrancescoConti]

axi/src/axi_pkg.sv

Lines 468 to 476 in ac5deb3

	typedef enum logic [9:0] {
	NO_LATENCY = 10'b000_00_000_00,
	CUT_SLV_AX = DemuxAw | DemuxAr,
	CUT_MST_AX = MuxAw | MuxAr,
	CUT_ALL_AX = DemuxAw | DemuxAr | MuxAw | MuxAr,
	CUT_SLV_PORTS = DemuxAw | DemuxW | DemuxB | DemuxAr | DemuxR,
	CUT_MST_PORTS = MuxAw | MuxW | MuxB | MuxAr | MuxR,
	CUT_ALL_PORTS = 10'b111_11_111_11
	} xbar_latency_e;

Logically speaking, it seems to me that the xbar_latency_e should be a logic vector (or a struct), not an enumeration. It makes logically sense to activate cuts for each channel separately and we have instances in which this is done (e.g., https://github.com/pulp-platform/pulp_soc/blob/f31c5a25f387432231be0bc6457a08fe47ce6f61/rtl/pulp_soc/soc_interconnect.sv#L277 ).
Under some (currently not so clear) conditions, this may trigger a Synth 8-9123 elab error in Vivado (seen 2023.2):

ERROR: [Synth 8-9123] an enum variable may only be assigned the same enum typed variable or one of its values [/home/fconti/pulpissimo/working_dir/pulp_soc/rtl/pulp_soc/soc_interconnect.sv:301]

It's not clear why the error is not always raised, note that enumeration is strongly typed in the SV standard as per IEEE 1800-2017 sec. 6.19.3. I guess other tools treat this simply as a logic [9:0], but why the error is not always there in Vivado is not clear to me atm.

[FrancescoConti]

@micprog was faster in proposing a solution than I am in complaining ;) #340