In the documentation of Gemini there is that you should

1. [Decompose][1] the original VCF such that variants with multiple alleles are expanded into distinct variant records; one record for each REF/ALT combination.
2. [Normalize][2] the decomposed VCF so that variants are left aligned and represented using the most parsimonious alleles.

http://gemini.readthedocs.org/en/latest/index.html

This sound like a good thing to do because is makes it easier to asign correct IDs and to compare variants.

Only problem I have seen mentioned is that for samples that have an ALT1, ALT2 genotype your genotype is now split over 2 vcf records; MISSING, ALT1 and MISSING , ALT2 . Or even REF, ALT1 and REF, ALT2 . Both don't correctly represent the genotype of the sample.

 [1]: http://genome.sph.umich.edu/wiki/Vt#Decompose
 [2]: http://genome.sph.umich.edu/wiki/Vt#Normalization
There are a few ways to skin this cat, and it is also an area with fairly active development. The central difficulty is that there often are multiple ways to represent the same variant in VCF, particularly in cases where block substitutions or indels are involved, and there is no "right" representation.

The decomposition/normalization approach has the downside that the process tends to destroy a lot of the good information that is contained in the original call set (e.g. phasing information, INFO/FORMAT annotations, quality scores). In addition, even after decomposition the results can be arbitrary (and so may not match up with with the coordinates you are getting your IDs from anyway, defeating the purpose).

An alternative approach is to have smarter comparison tools which are directly aware of representational ambiguity, by performing variant comparison at the haplotype level. AFAIK [CGI calldiff][1] and [RTG vcfeval][2] were independently the first to implement this strategy, and new tools are finally catching on, in varying stages of development ([SMaSH][3], [vgraph][4], [hap.py][5]). These tools replay the variants from the VCF into the reference and determine whether variants match by whether the resulting haplotypes match. With vcfeval the full VCF annotation information is preserved during the comparison (not so with hap.py, vgraph doesn't currently output VCF, and I haven't used calldiff or SMaSH)

In particular, the haplotype comparison tools are the current state of the art for same-sample call-set comparison (either between callers, or comparing with a benchmark set) -- certainly in the case of vcfeval this was the motivating driver in the development. The decomposition/normalization approach is more useful if you want to establish a population-level database where variants are converted to a "canonical" form with limited annotation requirements. Of course there is nothing to say you cannot use both techniques, depending on what you are trying to achieve.

 [1]: http://www.completegenomics.com/public-data/analysis-tools/cgatools/
 [2]: http://realtimegenomics.com/products/rtg-tools/
 [3]: http://smash.cs.berkeley.edu/
 [4]: https://github.com/bioinformed/vgraph
 [5]: https://github.com/Illumina/hap.py