So, I took the plunge and installed ES6 RC1 yesterday. Having prepared thoroughly since my rant here 6 months ago, the transition was straightforward. Whatever the merits or otherwise of the update, non-upward-compatible changes requiring extensive code modification, as this did, is still a very bad idea IMO. And as I expected, it did introduce some bugs where I'd overlooked things back in May. I now have 37 indices per "database" instead of some 50 types per single index (I took some, that were effectively just system configuration out of ES altogether, and some former types are sufficiently similar to share the same index with my own "type").
I adopted a convention of indexes called databasename_version_typename and aliases databasename_typename, which makes it easier to automate many of the things I did using types previously. I still think it would be helpful to have some built-in support for grouping indexes. If I have three "databases" in one cluster, I have 100 indices in this monolithic flat structure, when it would be helpful to group them by "database".
Anyway, I clearly did a good job as I only hit two problems (so far) with ES6 (including reloading all my indices, so I wasn't relying on the v5 index compatibility): the removal of 'created' in the result from posting a new document, which was trivial, and the new requirement for cURL put/post to explicitly have the Content-type:application/json header, which isn't the default.
The former is documented, but I don't see the latter in the list of breaking changes. I probably already should have had that header, but given the default worked previously, it's hardly surprising it was omitted in some places.
Also, I don't see the removal of (multiple) types listed in breaking changes. As this is the single-most, overwhelmingly important change in version 6, I really think it ought the right at the front, dead centre of breaking changes. Yes, it's documented later on, but even then it's only a footnote link (albeit marked important) on the indices API page. OK, you could argue as that 6 supports 5 indexes, it's not breaking change, but in some ways it's worse - if you started off with a v5 index in v6, but then had a catastrophe requiring a reload from backup, you'd find your whole app was broken and you'd be in deep trouble.
Also, I think it would be helpful to change all the documentation examples from .../twitter/tweet/... to .../twitter/unused/... or .../twitter/x/... to make it more clear that the type part no longer provides any functionality, and throughout reword phrases like "The PUT mapping API allows you to add a new type to an existing index, or add new fields to an existing type" as if there was the possibility to have more than one - the word "an" suggest that. Basically, to remove the documentation references to type, except that you have to have something, which is now irrelevant, in the URLs.