How is Permission Set Metadata Deployment changing in Summer '17 (API 40.0)?

By fully retrieving all permissions all the time, it will avoid the various Bad Things that happen when you only retrieve a partial package. This would lead to the XML file spuriously growing very large/small simply based on how the tool you're using decided to retrieve your org's metadata (e.g. a partial retrieve would result in a partial permission set, causing artificial changes that you'd have to continually revert, merge, resolve conflicts, etc). In other words, your source control system will be happy, merges will be happy, deployments will be happy (at least, in theory).

This is part of a larger change that's been rumored, where we will eventually be able to point a source control tree at an org and say "make this org exactly as specified from this source control." No more unexpected surprises, since we will be able to literally recreate an org as it existed at any point in the source control system, potentially even to the point of deleting classes, pages, fields, objects, etc. Of course, all of this is part of the new Salesforce DX experience. Salesforce wants developers, particularly ISVs, to have modern deployment capabilities, and a consistent deployment is part of that vision.

It's okay to retrieve from version 40 and deploy as a lower version, but retrieving as a lower version (e.g. 39) and deploying as 40 may delete permissions that were previously set outside of source control. This is a good thing, because we don't like unexpected permissions, but it does mean you need to get a clean retrieve first. Only deploy a file using 40 or above if you are certain it was retrieved from 40 or above. Your package.xml states the version the API runs with. Realistically, this is a once-per-source-control change developers will need to perform.

The Force.com IDE will automatically capture the new permission sets as part of the Upgrade Wizard that pops up with each new release, so there's little danger of something going wrong there. Developers using other systems, like the Migration Toolkit, must make sure that the first thing they do after changing to version 40 is a full refresh before making any permission set-based deployments.

Here is what I infer from the email and my experience with salesforce metadata API

Permission set does not have API version tied to it in the metadata XML file .So the question on how do I determine the version of permission set ?It is the version of package.xml that we must be aware of .

So lets answer the queries

1.How can you determine the API version of any tooling to see which of the two behaviors will be applied?

Its from package.xml version .

<version>37.0</version>

2.What will happen if you retrieve metadata about Permission Sets from v39.0 and then deploy that metadata with v40.0?

Since you are deploying with v40.0 while you have retrieved using 39.0 no overrides should happen .The mail mentions that junction metadata related to the PermissionSet is not retrieved with 39.0 while v40.0 bring all the related metadata like CRUD access and apex along and potentially could overwrite .

3.How will this benefit storing Permission Set metadata in source control?

The dependency is also maintained in your source control automatically without you having to manually worrying about adding dependency metadata to the source control .

To test this as soon as I will have v40.0 org ,summer 17 pre release org ,you will need to create an unmanaged package with permission set added to it and clicking on add dependencies should add all the dependent metadata related to the permission set automatically or I guess salesforce will automatically add all dependent metadata for us .This is consistency to me which platform was missing from long time .