From @usev6

bartolin m​: my Str @​a = (1, 2);
camelia rakudo-moar 1fdb76​: OUTPUT«Unhandled exception​: Type check failed in assignment to '@​a'; expected 'Str' but got 'Int'␤ at <unknown>​:1 (/home/camelia/rakudo-inst-1/languages/perl6/r​untime/CORE.setting.moarvm​:throw​:4294967295)␤ from src/gen/m-CORE.setting​:15614 (/home/camelia/…»
bartolin m​: my Str @​a = (1, 2); 1
camelia rakudo-moar 1fdb76​: ( no output )
bartolin why didn't the second command not blow up like the first?
  s/not//
TimToady m​: { my Str @​a = (1, 2) }; 1
camelia rakudo-moar 1fdb76​: OUTPUT«Type check failed in assignment to '@​a'; expected 'Str' but got 'Int'␤ in method REIFY at src/gen/m-CORE.setting​:10856␤ in method reify at src/gen/m-CORE.setting​:9466␤ in method gimme at src/gen/m-CORE.setting​:9949␤ in method sink at src/gen/m-…»
TimToady m​: { my Str @​a = (1, 2); 1 }; 1
camelia rakudo-moar 1fdb76​: ( no output )
TimToady looks like a bug relating to explicit sinking somehow
psch m​: my Str @​a = 1, 2; 1; @​a[0]
camelia rakudo-moar 1fdb76​: OUTPUT«WARNINGS​:␤Useless use of constant integer 1 in sink context (line 1)␤Type check failed in assignment to '@​a'; expected 'Str' but got 'Int'␤ in method REIFY at src/gen/m-CORE.setting​:10856␤ in method reify at src/gen/m-CORE.setting​:9466␤ in met…»
TimToady m​: sink my Str @​a = (1, 2);
camelia rakudo-moar 1fdb76​: OUTPUT«Type check failed in assignment to '@​a'; expected 'Str' but got 'Int'␤ in method REIFY at src/gen/m-CORE.setting​:10856␤ in method reify at src/gen/m-CORE.setting​:9466␤ in block at src/gen/m-CORE.setting​:9449␤ in method reify at src/gen/m-CORE.…»
psch that points to laziness, doesn't it?
TimToady m​: lazy my Str @​a = (1, 2);
camelia rakudo-moar 1fdb76​: OUTPUT«Unhandled exception​: Type check failed in assignment to '@​a'; expected 'Str' but got 'Int'␤ at <unknown>​:1 (/home/camelia/rakudo-inst-1/languages/perl6/r​untime/CORE.setting.moarvm​:throw​:4294967295)␤ from src/gen/m-CORE.setting​:15614 (/home/camelia/…»
psch i.e. the array assignment is lazy, and the 1 in sink context makes it not care?
TimToady pseudo assignment should be eager on my (though not on constant)
* psch mentally shoves that on the "GLR-problems" heap
TimToady m​: our Str @​a = (1, 2);
camelia rakudo-moar 1fdb76​: OUTPUT«5===SORRY!5=== Error while compiling /tmp/5lWhIQ3auG␤Cannot put a type constraint on an 'our'-scoped variable␤at /tmp/5lWhIQ3auG​:1␤------> 3our Str @​a7⏏5 = (1, 2);␤ expecting any of​:␤ constraint␤»
TimToady well phoo
* TimToady thinks our should at least allow identical type assignments
  /assignments/constraints/

AFAIU assigning elements of the wrong type to a typed array should lead to an exception regardless of what code follows.

From @usev6

On glr the evaluation dies with X​::TypeCheck​::Assignment​:

$ perl6-m -e 'my Str @​a = (1, 2); 1'
WARNINGS​:
Useless use of constant integer 1 in sink context (line 1)
Type check failed in assignment to '@​a'; expected 'Str' but got 'Int'
  in block <unit> at -e​:1

The test in S09-typed-arrays/arrays.t was unfudged with commit Raku/roast@f5c11d03d2.

I'm closing this ticket as 'resolved'.

@usev6 - Status changed from 'new' to 'resolved'