G’day and welcome to the forums.
Pull up a chair, this is a long one …
Re. your point 1, DNS outbound requests will work if you have an Application Policy to cover it. It doesn’t require a Global Policy as well.
Re. your point 2, I’ve never had a problem with zones, other than my own stupidity creating broken rules. This, I believe is known as “dumbage” - damage caused by an idiot). I suspect that there is a slight (handful of seconds) lag when a new zone is defined. I make a habit of rebooting if I have made major changes to the firewall,just to ensure the new config is initialised.
Re. your point 3, I know you can’t rename a zone and have the new zone replace the old name in any previously created rules that used the old name. This is a PITA and has been around for a while. It’s almost passing “bug” status and gaining “charming quirk” status. 
Hopefully, one day, they’ll fix it.
Re. your point 4, you currently can’t just disable a rule, although this has been previously requested and added to the wishlist. Comodo are exceptionally responsive to user suggestions, so feel free to reinforce this in the Wishlist topic.
Re. your point 5, no but this is a good idea. Please add this to the Wishlist as well.
Re. your point 6, as follows are my “hand rolled” Global rules
RULE 0
Action : ALLOW
Protocol : IP
Direction : OUT
Description : HOME LAN zone outbound
Source Address : ANY (In CFP speak, this is your PC)
Destination Address : ZONE - HOME LAN (Previously defined to include IPs only from home network)
IP Details : ANY
RULE 1
Action : ALLOW
Protocol : IP
Direction : IN
Description : HOME LAN zone inbound
Source Address : ZONE - HOME LAN (See above)
Destination Address : ANY (In CFP speak, this is your PC)
IP Details : ANY
RULE 2
Action : ALLOW
Protocol : IP
Direction : OUT
Description : ACTIVESYNC zone outbound
Source Address : ANY (See above)
Destination Address : ZONE - ACTIVESYNC (Previously defined to include IP only from PDAs)
IP Details : ANY
RULE 3
Action : ALLOW
Protocol : IP
Direction : IN
Description : ACTIVESYNC zone inbound
Source Address : ZONE - ACTIVESYNC (See above)
Destination Address : ANY (See Above)
IP Details : ANY
RULE 4
Action : BLOCK (Logging activated)
Protocol : ICMP
Direction : IN
Description : Detect inbound ICMP
Source Address : (EXCLUDE selected)ZONE - HOME LAN (See above)
Destination Address : ANY (See Above)
ICMP Details : ECHO REPLY REQUESTED
Explanation
Rules 0 and 1 allow communication between local LAN nodes, providing the application requesting the outbound or inbound access has an Application Policy that allows it.
Rules 2 and 3 allow communication between the local PC and a connected Windows Mobile PC (this zone (ACTIVESYNC) has addresses in the 169.254.2.X range and the zone is defined accordingly), providing the application requesting the outbound or inbound access has an Application Policy that allows it.
Rule 4 blocks and logs all ICMP ECHO REPLY REQUESTED packets, except for those originating in the HOME LAN zone.
That’s it as far as my Global Policies go. Note that there are no inbound rules, other than the local LAN ones, except for the BLOCK with EXCLUDE one. When I need to run an app that can accept an inbound connection, I load a config that contains that rule. When I no longer require the inbound rule, I drop that config and load my standard one (The import, export and management of configs are done in CFP - MISCELLANEOUS - MANAGE MY CONFIGURATIONS).
A little tip for configs - importing a config doesn’t make it active. To make it active, you need to choose the newly imported config using the SELECT button. All of your currently imported configs are listed under SELECT, so this makes it very easy to switch between configs.
The key to tight control really lies in the Application Policies.
If you are using CFP out of the box, the firewall will prompt for access whenever an application attempts inbound or outbound comms. How tight the auto created rule is depends on the level selected in Firewall Behaviour Settings (CFP - FIREWALL - ADVANCED - FIREWALL BEHAVIOUR SETTINGS - ALERT SETTINGS). Setting this to VERY HIGH will produce an application specific rule that specifies Direction, Protocol, Source/Destination Address and Requested Port. Lower settings produce correspondingly looser rules.
Re. your point 7, the HIPS (Defense+) pre-defined rules for specific topics (Web Browser etc.) are reasonably tight, but Trusted Application pretty much grants open slather rights. If you want to do it the hard way, you can create your own pre-defined application types. For example, I have an application type of SAP, which allows access on ports 3200-3299, 21490, 1432 and 11980. This allows the SAPGui outbound access, an inbound local service connection and a SAP install modification to be done.
It’s really up to you how to define them. If you trust your apps, let them be trusted. If you want to hand roll everything, you can.
Sorry this is so long, but I hope this helps your migration from Kerio to CFP.
Hope all this helps,
Ewen 