Hey @sebastian,
thanks for taking the time to have that detailed look on our prototype. I really appreciate your comprehensive feedback and will try to give some insight on what our thoughts on this are:
We agree that validation is a huge concern when dealing with this kind of data structure (which not only regards the store but also actions for example). @inkdpixels already had a look on GitHub - molnarg/js-schema: Simple and intuitive schema validator for validating actions on reducer level - it could be helpful for the store as well.
But I feel that the schema (with whatever tool it will be described) should not be our single source of documentation regarding the store. To completely understand the overall data flow, besides the static structure of the store, one must understand what smart components expect the store to deliver and what portion of the store reducer functions are going to mutate. Component-wise, I think, the @connect decorator does a great job for developers to immediately understand what section of the store is displayed by a component. Reducers on the other hand will profit from unit testing.
I also agree with @dimaip that testing will be worth a great deal to support the contractual character of the store, but runtime validation is definitely also important, since it helps to sort out corrupt server state.
I have been pretty overwhelmed by this as well when I started working with these tools. But after a while, I was under the impression that this speed of progress is actually healthy. Whenever a particularly better solution comes up for a problem, there’s no better time than right now to fix it. And the smaller your dependencies are (in amount and size), the more easy it will be to manage updates for them. Luckily, most of the npm-libraries innovate as fast as they ship, so change is not introduced in huge amounts. This might be just a feeling of mine, but I think that adopting progress doesn’t look like one, but is an overall time-saver.
I like the idea, but I would be afraid of this to die pretty quickly (just my experience with '.md’s other than README). But I do see the point of documenting third party libraries in such a way, so I would give it a shot.
I agree with prioritizing the recreation of the current UI, with keeping the benefits of some new paradigms in mind (like the I-Frame integration) - so that we will once in a while reflect on exisiting features, when and if they could be replaced with a better solution along the way (I don’t have anything particular in mind, but I feel like we should not be dogmatic about things, when there’s something better and more work-effective ahead).
The one I can not easily agree with is CK. I absolutely respect the level of sophistication behind this software, and certainly think that it is superior to aloha, but I do have great doubts if it is the right solution for Neos. It is just huge! Why should Neos integrate a Rich text editor, that looks like it aims to be a CMS itself? In my daily experience working with Neos, I always try to restrict the feature-set of Aloha (Which I can’t even do to the degree I would like to). With CK, I would have to reduce the feature set of a battleship down to that of a canoe - for me there would literally never be a scenario in which I could use a full blown CK in a project.
Of course I can only speak for myself, but I think this is a question of how much control you would like give up for a larger rich text editing experience. I always felt like restriction is the way to make the system more usable for editors.
I could live with CK as the editor shipped with Neos though (assuming it works as an npm depency) - but I absolutely disagree on the integrational part.
Our prototype is already agnostic about inline editors and I really would like to keep it that way. When Neos is actually able to provide a way to extend the inline editing feature with custom inline editors, this would be a huge win for the end users.
…
So, now I’ve written a lot myself 
I’m very happy about all the great and constructive feedback so far and really have the feeling, that we’re on the same page on most of the issues. And I’m really looking forward to figure out solutions on the remaining ones with you guys
@sebastian Thanks for the PR’s btw 
Have a nice weekend!
Wilhelm