Az a baj a többszálúsággal, hogy lehetnek nem kiszámítható sarokesetek, versenyhelyzetek.Ez általánosan igaz bármilyen többszálúságra, semmi köze az SMGUI-hoz. Ha több szálon akarod matatni a layout-ját, az a Te dolgod, Neked kell a szemaforokra odafigyelni. Maga az SMGUI sohasem ad hozzá vagy vesz el ebből a listából. Sőt, akárhány ilyen listád lehet, és váltogathatod is őket (egyik tab, másik tab stb.)
Egy GUI esetén semmi nem indokolja a többszálúság szükségességét.Dehogynem. Lenyomja a gombot a felhasználó, és amíg végrehajtod, amit ilyenkor végre kell hajtani, addig nem válhat müködésképtelenné a felület. Immediate-mode esetén erre esélyed sincs, amíg a végrehajtás tart, addig szükségszerűen lefagy a felület. Callback-nél nem, de azt meg szopás használni, külön függvény kell minden gomblenyomáshoz meg check box kattintáshoz stb.
Feltételezve, hogy van egy aszinkron API-nk mint Javascriptben.Már tisztáztuk, hogy minden aszinkron API - a Javascript motorok pedig különösképpen -, erdendően többszálúak. (Akkor is, ha a többszálúság csak a motorháztető alatt található és nincs direktben kivezetve a JavaScript API-jára, még akkor is. De egyébként pont a JavaScript async API-járól ORDÍT, hogy többszálú, mit gondolsz, a Promise miért closure és nem kontrollstruktúra?)
Alapból egyszálú a modell, vagy eleve az a modell, hogy vagy egy UI szál, és a program többi része külön szálon fut?A modell az, hogy teljesen tök mindegy, hogy a program többi része egyszálú vagy többszálú-e. (Nincs globális állapot, csak kontext, és az egyetlen függvény, ami különböző szálakról is hívható, egy atomi művelettel állít egy bitet egy volatile változón és ennyi.) Amit a sucklessről írsz, annak se füle, se farka. Kb. mintha azt mondanád, hülyeség az egész foci VB, mert az egyik csapat tök béna. Na kb. ennyi értelme van annak, amit itt írtál.