Some quick responses:
@Donavin and Weatherboy: I don't use DAM, so most of the bug reports involving DAM confuse me. When you say it "said it should", that was DAM reporting on what SS considered its most likely stasis action at the time. Don't know what to tell you.
@Weatherboy and Theraze: I had the same dilemma when scripting this -- originally I wrote it to ID only one bang potion per fight, but I opted to change it, in the interest of speed trumping survivability. However, I think I should probably change the logic for bang potions. Since spheres have entirely helpful results, they can be ID'd all in one go without much risk (plus you almost never acquire them all at once), but bang potions, if you add them all together, end up buffing the monster. Plus, unless you're backfarming them, you have a lot more time in a run to ID bang potions than you do spheres. So, I think I'll reduce bang potions to no more than ceil(die_rounds() / 10.0) per fight. That number was chosen fairly arbitrarily, but I think it will do nicely.
@matt.chugg: Thanks for reporting; this is an apparent bug in the way SS and KoL handle once-only items. SS removes them from consideration after use, but KoL doesn't -- the BALLS "hascombatitem" condition evidently still returns true despite not being able to use it. We'll need to test this by submitting the macro "use 5561; repeat hascombatitem 5561". If this throws an error rather than continue as normal, SS will need an additional check to avoid the error.
While I was checking up on this, I noted that the cup was missing stun information in batfactors. Added.
@rlbond86: I don't have a medium yet, so haven't written any support for it. I imagine it will happen, someday.
@Glazius: There may be a problem, but I don't think you've identified the cause. SS completely ignores mafia's round count, preferring to parse the round from the page text, so whether or not mafia miscounts is a non-issue. I'd like to see some output where this happens, please.
@Theraze: I beg to differ -- you're not burning time, you're profiting. Also, SS is underestimating, eh? It uses attack_action(), plus a one-round safety margin; it's not just an arbitrary round number decision. I suppose increasing the safety margin, while theoretically suboptimal, would reduce the number of bug reports, however. I'll bump it up a bit.