> Do we want to sort the table by (numeric) paper number, or by
> section number? Whatever we do, it might be good to specify the
> sort order in the introductory prose so that updates are
> consistent.

I think by section number will be more useful to more people. And as I said, I haven't yet have time to work on the introduction, but that would certainly be a good thing to point out.

> For some of the macro names, I have the gut feeling that we
> need to read the original paper to come up with a slightly
> more to-the-point name. "robust_sequences" sounds just too
> generic.

Indeed. I probably spent no more than ten seconds on any individual name, and no doubt it shows.

> This one:
>
> __cpp_lib_header_dynarray
>
> as predefined is a bit unfortunate. In general, the compiler core
> won't know which headers its standard library provides.

You're right it's unfortunate, but it seems almost inevitable. That proposal defines a new header. If you try to include it and it's not there, compilation will probably die violently. If we already had some way of recovering gracefully from an inclusion failure, we'd be ahead of the game. But since that feature wasn't already in C++11 (or earlier), we can't use it to bridge the gap to C++14. [sigh]

> I don't think __cpp_new_merging is required: This making the
> rules more strict. Any program satisfying the stricter
> rules also satisfies the more relaxed C++11 rules. Why would
> anyone need to check?

Perhaps this wouldn't be useful. I included it because I wasn't sure.

Clark