I think we need an improved design for block parsing and serialization/deserialization. This can be thought of as a follow-up / companion issue to #390 which discusses data storage.

I think this is an important set of technical decisions to get right before people start building plugins on top of our new structure. Here is the way I would like to see this work:

• Blocks declare the kinds of semantically meaningful markup they can understand (including where they expect key data to be stored) when they are registered. For example, for a gallery block, this would look like a set of figure and figcaption elements that point to WP images, probably using data- attributes to describe things like image IDs.
• There is a centralized or at least "recommended" parsing process that deserializes block data from this schema and reports any errors, downgrading to the "generic html" block if key information is missing. This process should be very robust and very easy for plugins to hook into.
• Splitting the post content into blocks and parsing out the data for each block should happen at the same time, in a single parsing step. This will become very important later as we add the ability to transparently upgrade shortcodes and chunks of "recognized" HTML markup to blocks.
• The same structure described above (specified during the block registration) is used to serialize block information when changes are made.
• If nothing about a block is changed (the user hasn't modified a block in the UI), its markup shouldn't be changed either, even if it's currently stored as a "legacy" structure like a shortcode.
• Lots of test cases for all of the above.

There is a lot to flesh out here, and a lot to be done, but I think that in the long run we will be much better served by providing standard and robust ways for blocks to parse their content now.