As discussed in comments, should avoid serialising content that is in production and that is being used by content editors.

The following is mentioned on Unicorns readme file on github.

NOTE: When deploying to a Content Editing or Content Delivery server, the Unicorn configuration should be trimmed down from development. Each config file in App_Config/Include/Unicorn has comments at the top designating what environment(s) it should live on. If you opt to use Transparent Sync as a deployment mechanism, make sure you > do not disable the data provider config file.

and

Don't use Unicorn to serialize actively versioned or workflow-enabled content (e.g. non-developer items). You can easily have two people create totally different "version 2" (or even v3, overwriting someone else's v2) content on different locations, and merging those is probably not what you want. It may be relatively safe during initial development if sharing test content, but be wary.

source: Unicorn Github

Also worth noting regarding serialisation of content is that, if it's being serialised and checked into git, at point of deployment, if unicorn is syncing what you have from git/release package to the instance to deploy to you'll end up overwriting content.

As for how the versions are serialised, from the assessment done in conversation of comments, we can see that it'll only ever serialise a field if there is a value.

  It will always store this value against the version it was first, placed in, however if the value changes then it'll add the field again against the version it was changed in.

As discussed in comments, should avoid serialising content that is in production and that is being used by content editors.

The following is mentioned on Unicorns readme file on github.

NOTE: When deploying to a Content Editing or Content Delivery server, the Unicorn configuration should be trimmed down from development. Each config file in App_Config/Include/Unicorn has comments at the top designating what environment(s) it should live on. If you opt to use Transparent Sync as a deployment mechanism, make sure you > do not disable the data provider config file.

and

Don't use Unicorn to serialize actively versioned or workflow-enabled content (e.g. non-developer items). You can easily have two people create totally different "version 2" (or even v3, overwriting someone else's v2) content on different locations, and merging those is probably not what you want. It may be relatively safe during initial development if sharing test content, but be wary.

source: Unicorn Github

Also worth noting regarding serialisation of content is that, if it's being serialised and checked into git, for purposes of Continous Delivery and Continous Integration. If you you run a sync with items you've serialised at development level when deploying to production you run the risk of overwriting live content with developer content, this is why it is best to avoid serialising much under /sitecore/content tree and it's worth ensuring that your unicorn configs are air tight as possible to prevent this.

As for how the versions are serialised, from the assessment done in conversation of comments, we can see that it'll only ever serialise a field if there is a value. It will always store this value against the version it was first, placed in, however if the value changes then it'll add the field again against the version it was changed in.