Option one:
This option does no interpretation of the advertising registry keys.
Pro: This is better than selfreg (running its internal registration code) because there will be no dependency problems. If you were trying to upgrade a locked file then you would otherwise have to reboot before registering it.
Con:
No special support for the MSI COM tables. These tables enhance the COM server by allowing it to ensure that its Feature is working before the COM is invoked
Difficult to manage shared files because their settings aren’t all neatly bundled with their component.
Many ICE33 errors when validating the package
File extensions are not counted in and out as programs are installed so when a program is uninstalled the filetype will have no association.
Option two:
This option interprets the advertising registry keys into the COM tables.
Pro: Enhances the COM server by adding self-healing to ensure that its Feature is working before the COM is invoked.
It is the approved, supported and normal way of packaging those files.
Note that there will still be many stray registry entries in HKCR. That is perfectly normal. Not all the settings are used by the special tables, so everything else remains in the registry table.
Con:
A little knowledge and experience is required to correct some of the issues that can arise.
Option three:
Have the settings in two places, the REGISTRY and the COM tables
Pro: Hmm the “belt and braces” approach. I suppose if you don’t know what you are doing and making them register twice helps and you have run out of other ideas then .. why not?
Con:
Getting this stuff to work in one place can be tough enough some days but having it in two places is twice the trouble

Very well Explained. Great job buddy !!!