Patching with Windows Installer is the act of applying a pair of transforms in a patch to a Windows Installer product, then repairing that product. Any changes made in the transforms affect the aggregate view that Windows Installer reinstalls. This is displayed in the diagram below, where the bottom layer is the components in the product MSI, the second layer is the changed components in the patch transforms, and the top layer is the aggregate view created by transforming the product.
Uninstalling a patch is acting in reverse: a patch transform is removed from the view and the product is repaired. Thus, any changes made in the patch are lost. The ability to uninstall a patch does depend on whether the patch MSP is authored with an MsiPatchMetadata table and that the table contains the standard AllowRemoval property with a value of 1.
That still doesn’t guarantee the patch is uninstallable, however. Major upgrade patches – which are supported but not recommended – and patches applied to administrative installations are not uninstallable. More subtle than that, modifying a handful of tables documented in Uninstallable Patches also makes the patch not uninstallable.
When the patch is removed from the view, information about newly added resources is lost.
This is also one reason that not every problem with the original Windows Installer-based installation can be fixed in servicing. Servicing is a repair of the product, and when a patch is uninstalled that information is gone. I mentioned this when warning against about type 35 custom actions, that changing the condition in a patch transform to prevent the type 35 custom actions from running during maintenance mode fails when the patch is uninstalled; affected components are not reinstalled and, thus, not reverted back to their pre-patch states.