It would make great sense for paged results array property to have a common name, items perhaps.
For those writing in languages that support 'generic' constructs, this would simplify the code dramatically. e.g. PagedResult<Users>.
For those writing in languages that don't support 'generic' constructs, nothing has changed except the name of the field.
It would make more sense - in my opinion - for a library to abstract the paged nature of results away entirely.
Furthermore, there's no need for the objects exposed by whatever deserialization code to reflect the naming scheme of the underlying JSON. If you want more automatic code, you could just define the data field as not total, page, or pagesize. The general case for API usage does assume a human reading the docs and writing the code, your efforts not withstanding.
A change with such a wide impact - literally every method in the API - isn't really practical this late in the beta cycle unless it were addressing a very real problem, which this frankly isn't.
