Looks like these are complications resulting from making the repeat conditions in the stasis macro more lax as an effort to reduce server hits for farmers. Previously, the stasis action would abort whenever (among other checks) your HP or MP changed at all. That meant that most skills would only be cast once per macro since they cost MP, and even free restores like Burrowgrub and Spring Raindrop would only run once due to the HP/MP gain. Then, BB would rebuild the combat options from your page text and skills which are no longer available would be absent from the list. However, this mostly translated to one server hit per action -- no different from non-macrofied play.
So the change made was to allow HP and MP gain without ending the repeat loop, until max MP/HP was reached, or until you have enough MP to cast your most expensive skill -- in other words, potential restore goals. This means far fewer server hits for farmers -- it cut one of my multis' daily operations time in half.
However, it looks like this should be reverted, since presently there are too many things which prompt KoL errors due to the source running out before the repeat conditions do -- I keep getting similar aborts from Burrowgrub running out, and these other reports lead me to believe that this was a change made too soon. Without a mechanism for knowing how many instances of an action are available, this change is causing more harm than good. I'll revert that and look for a better way to reduce server hits.
Also, for future reference, whenever mafia aborts the combat without any specific error message (technically after SS is done), it's safe to assume it's due to SS's previous macro prompting a KoL error. That's what the deal was before with "pickpocket; repeat", and with Noodles vs. unstunnable monsters, etc. These errors are good because they help us iron out flaws in BatBrain's combat foresight and macrofication, but they're annoying in that they're pretty hard to track down.
If, after I revert the stasis loop conditions, you still get one of these mystery errors, please post the combat with verbosity 9 so we can see the macro being submitted -- ideally with the actual resultant page text from submitting that macro, as asturia did above. Being able to see the actual KoL abort error is very helpful. Thanks.
EDIT: Long ago I aliased that run_combat command, but recently I added a line so now it's "fight => ashq refresh_status(); run_combat();" -- it's pretty handy. That refresh_status is necessary because if your connection timed out simply calling run_combat() won't prompt a login.