, I'll just try and get through replies sequentially.
Moon Saber Defense?
I've figured out part of what is probably happening. The first thing Saber spells do is clear remaining saber uses then call the NPC stat setup code to revert their weapon's element. This code reloads all their stats though, so something must be causing this to grant them more defense than when they initially spawned. Not sure why they wind up with more defense (or maybe avoidance? I haven't verified what stat is changing).
The enemy type doesn't determine whether an enemy is pushable. The data that puts enemies on a given map controls whether that specific enemy (or NPC, chest, crystal orb, etc.) will be pushable or not. So if a map has say, a Rabite, and it's flagged as pushable (which would be typical), and Day/Night Cycle replaces it with an Eye at night, that specific monster spawn point is pushable. Likewise, a map with an Eye enemy, if it's instead a Rabite at night, that Rabite won't be pushable.
Also, I haven't verified this myself, but I recall reading that if an unpushable enemy spawns adds, they also won't be pushable. Probably worth checking that those Eye-spawned Chobin Hoods and Weepy Eyes are actually pushable.
Griffin Hand <-> Mushgloom?
Yeah, just so that they trade places at night to spice things up.
The term "bug" (specifically software bugs) is ill-defined. Some people use it to mean anything that doesn't work as expected. Some people use it only for physical hardware defects that affect the software unexpectedly. Most people use it loosely somewhere in between those two extremes. It often hinges on how much blame you want to put on the programmer's competence vs. acceptance that perfection isn't realistic (calling a programming mistake a "bug" downplays that a human was responsible).
Personally, I generally use the term "bug" when the programmer had the right idea in mind but messed up the implementation (to err is human), and "design flaw" when what they had in mind won't work no matter how well programmed (their logic is bad and they should feel bad). The former is an accident, the latter is incompetence. Don't get me wrong, I make tons of design flaws; I rarely call mistakes I make bugs.
I don't actually know what I'd call a nighttime enemy being in the wrong pushable state than expected. It's so technically unimportant that I don't think it's worth roasting someone over it, so I guess I'd just call it a bug. You could blame me for not having a mechanism in Day/Night Cycle that can accommodate the change (though I don't intend to implement that, as it works at the enemy index number level, not at the spawn point level) and accept the limitation and just only swap pushable with pushable and unpushable with unpushable, or just disregard it and don't sweat that some enemies won't be in the right state.
Auto_Talk_Fix fixes what I consider a bug: the programmer accidentally had the A register in the wrong bit mode on a certain code path (in some complex looping code) which caused a crash. Mana_Magic_Unequip_Fix fixes what I consider a design flaw: it works as designed, but the logic is bad so it not only behaves poorly when the boy has the level 9 sword equipped, but it double unequips their weapon (as each of the two different Mana Magic buffs fades). Lots of things in the "bug fix" section I consider fixes to design flaws and not bugs.
Ultimately, none of it matters, I just occasionally indulge in pedantry.
Dust Flare stuff?
I'll get those changes in. I consider the Fire Gigas to be one of the hardest bosses with default Turbo settings already, hence why I had to get the engulfing Lava Wave out of his repertoire.
, I entertained the idea of only one of the whip attacks pulling when I implemented it, but unfortunately there's currently no means to tell the two attack types apart when the knockback needs to be applied. You can tell what weapon type applied the damage (so that whips can pull and gloves can always trigger a knockback), but there's nothing that differentiates the two whip attacks.