The -d exact behaviour isn't a bug, dedup is meant to collapse identical records, so when both platforms call the same variant one copy goes. It just doesn't sound like the operation you want.

Two things. Normalise each VCF separately before combining rather than after -- left-aligning and splitting multiallelics is what makes the same indel written identically in both callsets, and if you only do it after merging the same variant can sit there in two representations, which quietly breaks both dedup and any intersection.

The bigger one: bcftools merge is for combining different samples. If Illumina and ONT are the same sample, a merge isn't really meaningful and what you want is concordance:

bcftools isec -p out_dir illumina.norm.vcf.gz

ont.norm.vcf.gz

That gives you variants called by both and variants unique to each, which is more useful than one flattened file where you can't tell which platform supported what. For DENV2 I'd lean on the intersection -- ONT-only indels in homopolymers are mostly systematic error, while SNVs both platforms agree on are about as solid as you get.