It's up to you to form your opinion, but here are the facts:
1) Before diskless replication: even a master with persistence turned down, had to persist on disk, in order to support slaves.
2) Because of "1", it looked like futile to support this model of operations.
3) "1" is no longer true, I merged the diskless replication stuff just this morning.
Still I don't think you can form a fully informed idea unless you consider this: if you have persistence turned on in a setup which uses replication, like in most deployments using replication, you absolutely want the old behavior of Redis, of slaves reconnecting and replicating again on master restarts.
So when I say, in the future this could change, it is just as an opt-in option in order to support this new use case, not to say, the old behavior was crazy.
It absolutely does preclude that because it's not how the system works. You've described a multi-master system while comparing it against a replication-only system. Apples and racecars.
leaving them out is unjustifiable.
Feel free to submit a pull request fixing any and all deficiencies you've found. :)
No, I haven't, unless you'd say it was already a multi-master system because it allows non-masters to continue without the master being present. What I'm suggesting is just a master being smart enough to recover its own state from where it had been replicated before. How is that even controversial? In what possible use case is it preferable to discard readily available data without an explicit user request to do so?
"Feel free to submit a pull request fixing any and all deficiencies you've found."
Give me some reason to believe it won't be torpedoed by the next bad decision or failure of diligence that comes to light, and I might. Acknowledging that this needs to be fixed would help.
"Old style" doesn't explain it. Even if the original master has unconditional priority when it returns, that does not preclude it gathering whatever data might still exist from the others. I've been working on replication systems since '92, and I can't recall seeing any that would make such a poor choice. Can you point to any, or is this really a "new style" idea?
"we can construct a reality or a model we both agree about."
I will concede that the behavior might be compliant with how the system was specified. I'm not 100% convinced yet, but at least - now - you've made a credible case for that.
"Then we can debate about what we think is right or not."
Not. The data-preserving mechanisms (e.g. view/epoch IDs) are so easy to implement in this case that leaving them out is unjustifiable. You even seem to be coming around to that view yourself when you say "in the future yes" but apparently you can't bring yourself to admit that it was always the right choice.