In comparing a 1PUX export from a few weeks ago, to one today generated by the latest Mac beta, it appears the uuid values are in transition.
It seems you are now generally writing 26 lowercase a...
That's what I needed to know, regarding import and the IDs. This tells me I'm safe doing the same thing, generating a random UUID.
I've also already discovered that (all of?) the account->attrs and the "uuid" and "desc" attributes of the vaults->attrs are ignored, and can be empty strings. And this makes sense.
As an example of the changes in recent betas, previously, a TOTP id used to look like:
TOTP_A52DD85453964186AF69747BAB83E183
Now, it looks like:
TOTP_mctcwehrqryafn3opmyqkijrai
So for I've discovered that all "id" and "uuid" values now use the 26-alphanum char scheme, including the prefixed the "id" for a totp (which includes the prefix "TOTP_"). The exception for me is accounts->atrrs->uuid, which was created a while ago, so retains the previous UUID format.
The converter suite's UUID style has always been version 4 (RANDOM) UUIDs - 32 hex char values (like that shown in the TOTP_####) string above. That seemed to be correct when I implemented the UUID generator; only later did 1Password start generating new UUID's upon import (it used to be possible to update entries via 1PIF import, as the UUID value was retained - this was actually pretty handy, but I understand the reason for the change).
Reviewing JSON and exports has shown that 1Password has been moving away from the 32 hex char to 26 char alphanums. Here you can see a portion of a somewhat recent record, that includes both versions: