Thanks for the verification, I really appreciate it!
I realize I should have mentioned that one of our goals is to move towards documenting a single, preferred way to do things. XLSForm has historically defined a lot of aliases which can lead to confusing examples and documentation. I realize there are tradeoffs here -- if people already use the less-favored way of doing something, they may find it confusing not to find it in reference. We think the overall value of presenting a single approach and having consistent examples and documentation outweighs that concern.
thousands-sep: good catch, have added that it applies to decimal and text numbers!
autocomplete: documented as its alias search
printer: deprecated; the Zebra print driver app and the printer it was designed for are no longer available. We'll be working on a way to build and send a document to a generic Android printer in the next Collect release.
new-rear: as far as I know it was never implemented anywhere
table-list: this is an alias for building a grid of selects. As far as I know it's not documented anywhere and looking at the pyxform code I'd rather we not expose it further. I've seen many forms with the "raw" grid building and it seems generally approachable to users.
Select appearances
There used to be differences between how Enketo and Collect treated select appearances. These were aligned as described in this thread.
compact: deprecated, use columns-pack/columns-pack no-buttons
compact-n: deprecated, use columns-n/columns-n no-buttons
horizontal: deprecated, use columns
quickcompact: deprecated, use quick as a modifier to any select one you want
Special Enketo behavior
distress: its more general counterpart is the range widget which can have a vertical presentation with ticks. We never discussed distress for inclusion in the ODK spec and it feels pretty specific.
streets, terrain, satellite, [other]: this depends on map layers defined in the Enketo configuration. I think it's best documented in Enketo.
w-n: this feels like it doesn't stand on its own. We chose to mention it in the hover description of the style setting only. Someone would have to read longer documentation on the grid theme to know what those appearances mean. That said, I'm on the fence about it and could be convinced if others would rather see it part of the appearance table!