I thought about the format of member names and the following questions came into my mind:

• Is there a format for (top-level) member names?
• Which characters are allowed (at special positions)?
• Are member names case sensitive?
• Can I use integers as members?

Suggestions:

• Periods (U+002E FULL-STOP, ".") aren't allowed, because it's used as the relationship path separator.
• Commas (U+002C COMMA, ",") aren't allowed, because it's used in the include parameter as a separator for multiple relationship paths.
• Members should not start with a digit ("0-9"), as this could be a problem when mapping API to the code, e.g. in PHP and C# object members of this type aren't allowed.
• Members should not contain a minus (U+002D HYPHEN MINUS, "-"), as this could be a problem when mapping API to the code, e.g. in PHP and C# object members of this type aren't allowed.
• Members should not contain a colon (U+003A COLON, ":"), as this could be a problem when mapping API to the code, e.g. in PHP and C# object members of this type aren't allowed. Also they could be reserved for later use in the include parameter?!
• When checking for duplicate members, members should be handled case insensitive, because they name a resource, which has special semantics, and this is independent from the spelling. When using member names in a request (e.g. with the include parameter), they should be handled case sensitive, because this would allow duplicate content for different spellings.
• Theoretically it isn't important if lower- or upper-case characters are used for the member names, but I'd suggest to always use lower-case, as this is the current format of the standard members and it would simplify the use by API clients.
• Underscores (U+005F LOW LINE, "_") should be allowed, as I don't know problems with underscores in member variables of any language. They could be used as the first character, but IMHO that wouldn't be good for readability.

Resulting format:
^[a-z]+[a-z0-9_]*$