I am both speaking on behalf of the Zcash Foundation, as its Executive Director, and sharing my personal assessments.
@hloo’s plan to create Ycash represents a truly user-driven exercise of voluntary exit, intended to change the trajectory of a project that he clearly loves. In general, forks (or plausible threats of forks) are powerful governance tools; so much so that it was one of the reasons the Foundation partnered with Parity to build a separate Zcash implementation. The Foundation is glad that @hloo is exercising his rights — Zcash is open-source software on purpose, in part to afford this freedom to users. We wish him well in the endeavor.
Forks and Friendliness
Forks are fundamentally political acts. Even in the case of a routine Zcash protocol upgrade: A successful upgrade ideally demonstrates a universal collective choice. If it were possible to force upgrades on everyone, instead of communicating the value and counting on people to decide to upgrade, it would be coercive. An unfriendly fork would mean that an upgrade was contentious enough to prompt a significant segment of users and miners to choose a different path.
A "friendly fork" is a strange beast, to be honest, and I’m not sure that I like the term. On one hand, close collaboration between projects with shared components and goals is worthwhile… but on the other hand, recent forks indicate that fracturing a community could dilute the value of both projects. So it’s possible that even the most amicable of forks could reduce the economic activity and value that otherwise would have remained within the first project. The friendliest fork is the one that doesn’t happen. 
That said, attempting to stop a fork when any user has the right to copy, modify, run, and distribute the software would be just as coercive as forcing an upgrade on users that didn’t want it. In my view, it’s better to have collaboration and alignment, rather than a more significant schism of the community.
I do have some open questions about the Ycash fork that I think are worth discussing.
First: One of the main reasons why you’re forking Zcash is concern that currently unmined ZEC will be redirected from miners in the future. You cite a promise about monetary distribution which you feel is in danger of being violated. Hence you want to create a new funding distribution scheme… which violates the same promise in the opposite direction, because it redirects unmined ZEC from the people who would receive it under the current rules. Do the old promises not apply to a forked blockchain? You could argue in either direction, and the cryptocurrency world is still establishing its norms. But it seems strange to ensure a promise (that has not yet been broken) by breaking it differently.
Second: As a consequence, the recipient of the funds you are redirecting is the Ycash Foundation, which will (eventually) have more YEC than any other Founders’ Reward recipient. This concerns me, as the structure of the Ycash Foundation is undecided (or perhaps decided in private), besides owning the Ycash trademark. (As an aside: Redirecting funds throughout the mineable lifetime of the blockchain indicates that you implicitly support some mechanism for long-term support, which seems to lend credence to the idea of a new dev fund for future Zcash work… though you hold the 2.1 million limit more sacrosanct.)
Third: Another primary motivation for this fork is PoW that works on "commodity" hardware, but it seems you’re launching with the current (ASIC-able) Equihash parameters? Given that this is one of your fundamental goals, wouldn’t it make sense to wait until you have committed to integrating a different algorithm that can actually keep "commodity" hardware viable? Particularly since this could put Ycash users at risk if hostile mining pools decided to engage in nefarious activity with accumulated Equihash power.
Fourth: I would generally discourage the use of the royal we in making proposals. It can be confusing in the case when you are not speaking for a multi-person team. I understand now that you were referring to the Ycash project, but that was ambiguous until clarified.
Fifth: It seems likely that promises around monetary policy would have to be modified if Ycash migrated to Proof of Stake (based on the need for continuous inflation in that system). You may even have to modify it for Proof of Work. (Based on some work on the instability of fee-based blockchains.) Maintaining low fees will make keeping the promise even more difficult.
Sixth: Per @nathan-at-least’s point, this could have a privacy impact on shielded users and it’s worth investigating before shielded users move funds on both chains.
For me (and/or the Foundation) as a potential Ycash user, I would care about these concerns being addressed. Particularly with respect to the structure of the Ycash Foundation and the need to fork with the current PoW (which puts Ycash in danger of being attacked by Equihash miners).
I do appreciate the design goals and the spirit of your plan @hloo. I wish you luck, as does the Zcash Foundation. We will continue to support Zcash (and thus Ycash downstream).
Permanence of Promises and Promises of Permanence
One final thought for the community’s consideration.
Now is a good moment to reflect on the permanence of promises, and the promise of permanence. This fork is motivated by @hloo’s view that promises have been broken, and are at risk of being broken again in the future. What if promises about Zcash or Ycash must be broken in the future to ensure their survival? Where do we draw the line?
My view is that if there’s a technical or economic reason to break a promise, the onus is on the proposer to explain why it’s worth it, and to cultivate broad, overwhelming consensus as best as they can. Just as the onus is on @hloo (and soon the Ycash Foundation) to encourage users of Ycash to restore promises that he sees as broken. Absent a polling or governance mechanism that can authoritatively describe consensus, perhaps the best measure will be how much an alternative fork catches on.
I am optimistic that a shielded pool polling mechanism can help, but it’s only one input in a sea of noisy data, and it’s possible for users to lack the information needed for a sound decision. I don’t have any concrete answers here, but the question is fundamental to the governance challenges of any protocol aspiring for decentralized power and decision-making.
