Alice is the hacker. Not necessarily in a bad way, but she is the hacker. I think the real concern is historical data integrity. If Alice within her fork removes certain parties from the history, how reliable is that history?
You can sort of get around this by freezing the account from making transactions preserving the history on the ledger but effectively nullifying it effects, but in terms of participation, that system is no longer 100% open or free. It is a system where stake has a history of being nullified.
So if the data integrity can not be preserved by the code (via existence or free participation) then it is a system of money that relies on trust. Trust that the parties in control (Alice and her friends, the majority will) won't nullify other participants that they view are bad actors. Such a system appears to be tainted by over governance.
So, I'm not going to call that theft or piracy or a heist. But it would be a reason (for me at least) not to participate in Alice's fork. Because I already participate in systems like that and look to blockchain technologies to move away from those types of systems.
Steem is already that, multiple times, even within the past year.
If you want a chain with decently strong immutability (at least since 2010 when the overflow bug had to be forked out), you want something like Bitcoin, not Steem.
In point of fact there is no history being changed in this story, only some accounts being prevented from making new transactions going forward. History itself is unchanged, and that is even verifable as Alice's chain links back to the original chain with all hashes intact, and indeed the other chain's participants share history and can been seen as a second set of witnesses to it. Of course other sorts of state-changes-by-fork are possible, and have been made on Steem.
Could you give an example? Out of curiosity's sake. Where stake has been nullified without the consent of the party being nullified.
(I know I didn't specify this above... but "burning" stake is technically nullification.)
Johan's HF21 was copied from HF9 which was implemented (unilaterally by Steemit using their ninja-mine aka "premine" to vote in their own witnesses) to reset keys (to a key known only by Steemit) on a bunch of accounts whose owners, including dan and ned, were careless and lost their keys. Not only that but the group of accounts was not exact, innocent third parties' accounts were also taken, some returned, some likely not (because they were unable to prove ownership to Steemit's satisfaction). I avoided losing accounts by sheer luck (the time window missed my accounts by a few hours). In a recent fork an account balance was reset as it was able to obtain extra coins due to a bug. There are numerous others I don't recall.
Steem is based more on governance and deciding (sometimes unilaterally by Steemit) on the 'best' approach, than on absolute immutability, for better or worse.
I guess that is fair. Some could argue "intent of code" ala Dan Larimer to differentiate between the two, but I've never found that to be a convincing argument. I guess this comes down to an "optics" thing. I think it might be cleaner to start a new chain rather than to fork, but I can see how certain parties might interest in a fork versus just starting a new blockchain.
Which is why I use and participate with Steem based on it's representational (and entertainment) value rather than treating it as "hard" money. That being said, forking is built into the code, so regardless of what one considers the action, such a proposal is built into the rules of this game.