I can't speak for all disciplines, but in my area (somewhere
on the boundary between theoretical and practical CS) I've never
met anyone who claimed that changes from the submitted
version to the final version of a conference paper
have to be restricted to those
issues that were spotted by the reviewers.
That means: yes, of course you may fix bugs – in fact, you are
supposed to. You may update experimental results, if you clearly
state that the results published in the final version were obtained using
Comcom-Moc, vers. 3.1.4, 2016-09-24. You may include better
examples, and you may add further explanations.
The caveat is that you may not make changes that might
have influenced the opinion of the reviewers negatively.
So, for instance, if you spot a bug in Comcom-Moc, vers. 3.1.3
(i.e., in the version used in the submitted version),
you must of course fix it, but if
the results for vers. 3.1.4 look a lot less
impressive than the results for the buggy old version,
you have to inform the editor – neither keeping the old results
(which are known to be invalid) nor silently replacing
them by the new ones (which are possibly no longer competitive) would be acceptable. The same applies if you find a bug
in a theoretical proof that can only be repaired by replacing
the main statement of the paper by something significantly
weaker.