Does this mean that all policies should use the same application name and port number?
Those who were familiar with older versions of the Firewall Enterprise (and Sidewinder) product had to deal with the same behaviour. You can have multiple service/application definition entries using the same port number, but only one of them can be used per zone. You can use the"mssql" service in a rule from external-to-DMZ, and use a different service/application (using the same port number) in a rule from internal-to-external (as the source zones are different). In v6, this was done by enabling/disabling the service on a per-zone basis and if you tried to enable a service where an existing service using the same port number was already enabled you would see an error. From v7 onwards it was no longer necessary to manually enable a service as it would be automatically enabled as soon as it is used by an access control rule.
When v8 was first launched and McAfee introduced the concept of Application definitions instead of services it was possible to have more than one application using the same port number applied in the access control rules. However, for reasons (which I will leave someone from McAfee to explain) when 8.3 was released they reverted back to a single active service/port number per zone principle.
To that end, if you give your application definitions more generic names ("tcp-1433", rather than "sql", for example) when this definition is used in different access rules for different purposes it could be considered to be less confusing for another admin looking at those rules. The rule name can be used to identify the difference. So if you have a rule in place to allow traffic to pass to/from a SQL server, you can use the "tcp-1433" definition, but call the rule something appropriate and if you then need to create an additional rule for another service that just happens to use TCP port 1433 as well, you can use the same definition, but name the rule in a way that makes it clear to another admin what that rule is designed to do.
Many thanks Phil for so great and detailed explanation