Clock Inference for unclocked sequence used as event control

SystemVerilog
, , ,
1

I am trying to understand clock inference for an unclocked sequence ‘seq’ used as event control @( seq ).
Here are 2 examples which I tried ::
(A) edalink1
(B) edalink2

Regarding (A) ::

[Q1] ‘seq’ matches at T:15, as a result @(seq) unblocks.
Why is that always isn’t triggered/unblocked at T:15 ?
LRM Figure 4-1—Event scheduling regions shows a loopback from observed region to active region. Unblocking of @(seq) is an example of it.

      My understanding is that always@(posedge clk1) unrolls to ::

 initial begin
    @(posedge clk1);
    $display("T:%0t always@(posedge clk1) unblocks",$time);
    @(seq);
    $display("T:%0t seq matches",$time);    
    @(posedge clk1);
    $display("T:%0t always@(posedge clk1) unblocks",$time);
    @(seq);
    $display("T:%0t seq matches",$time);    
   @(posedge clk1);
    $display("T:%0t always@(posedge clk1) unblocks",$time);
    @(seq);
    $display("T:%0t seq matches",$time);    
    .........
end

[Q2] In absence of default clocking block ( i.e by passing +define+NO_CB ), why doesn’t ‘seq’ inherit the clock ‘clk1’ from always block ?
Why is it that a concurrent assertion embedded within always block can inherit the clock ( Eg: EDA_Unclocked_SVA ) but @(seq) can’t ?

Regarding (B) ::

My understanding is that similar to a1 from thread, ‘seq’ would infer clocking event as @(posedge clk2)

There are 4 scenarios
(1) +define+TRIGGER +define+SAME
(2) +define+TRIGGER
(3) +define+SAME
(4) No +define passed

[Q3] Is the code for (3) and (4) legal ? i.e using @(seq) in consequent. I observe that 2 tools throw a compilation error

I observe that for (1) and (2) ‘seq’ infers clocking event as @(posedge clk2) , shouldn’t (3) and (4) infer the same clock ?

[Q4] Shouldn’t the output for (1) and (3) match ? Similarly shouldn’t the output for (2) and (4) match ?