(English title above; details in Chinese for accuracy. Machine translation friendly.)
编译模式下，“广播并等待”与“背景并等待”的行为不一致
预期行为
在开启 运行时不刷新屏幕（warp 模式）的自制积木中：
解释模式下：广播并等待 和 换成背景并等待 都会被压制（即卡死）。
编译模式下，应该和解释模式一样卡死。
实际行为
编译模式下（TurboWarp v1.15.5）：
广播并等待 不会被压制（不导致编辑器卡死）。换成背景并等待 仍会被压制（卡死）。
最小复现
（编辑器是否卡死，可通过观察角色是否流畅旋转来判断）
（记得开启“循环计时器”）
一些分析
通过查看编译后的代码，提取了两种积木的编译产物：
广播并等待 生成 waitThreads 函数，内部循环末尾直接 yield，无 warp 条件判断。换成背景并等待 生成 executeInCompatibilityLayer，内部有 if (!isWarp || isStuck()) 条件， warp 模式下不 yield。
猜想
可能是有意设计（因为广播并等待不被压制可以用于 warp 模式下等待其他线程），但也可能是历史遗留。
无论哪种，当前行为不一致会给开发者带来困惑。
期望
- 这是否为预期行为？
- 若不是，是否可以在未来版本统一？
- 若是，是否可以在文档中注明差异？
(English title above; details in Chinese for accuracy. Machine translation friendly.)
编译模式下，“广播并等待”与“背景并等待”的行为不一致
预期行为
在开启
运行时不刷新屏幕（warp 模式）的自制积木中：解释模式下：
广播并等待和换成背景并等待都会被压制（即卡死）。编译模式下，应该和解释模式一样卡死。
实际行为
编译模式下（TurboWarp v1.15.5）：
广播并等待不会被压制（不导致编辑器卡死）。换成背景并等待仍会被压制（卡死）。最小复现
（编辑器是否卡死，可通过观察角色是否流畅旋转来判断）
（记得开启“循环计时器”）
一些分析
通过查看编译后的代码，提取了两种积木的编译产物：
广播并等待生成waitThreads函数，内部循环末尾直接yield，无 warp 条件判断。换成背景并等待生成executeInCompatibilityLayer，内部有if (!isWarp || isStuck())条件， warp 模式下不yield。猜想
可能是有意设计（因为广播并等待不被压制可以用于 warp 模式下等待其他线程），但也可能是历史遗留。
无论哪种，当前行为不一致会给开发者带来困惑。
期望