Description of problem: On installations where may be installed packages with the same name but for different architectures, like for x86_64, the following may occur. Let say that we have on a system 'package.archA' and 'package.archB' and for whatever reasons (availabilty or a partial failure) yum attempts to update only a 'package.archA'. One possible outcome, when both packages have some files in common, is that the whole transaction fails with complaints about file conflicts which are somewhat "mysterious" until one start to look very close at versions and architectures (which seems too confusing and difficult for many users). The other, actually worse, situation is that an update of one of these packages gets through. Subsequently it will be not noticed, I think that on an rpmlib level, that the other package from the pair needs an update too even if it will become availalble and/or possible. An example of the later in practice happened recently with updates to FC3. If both libwpd-0.7.2-1.i386 and libwpd-0.7.2-1.x86_64 were installed, with i386 variant used by openoffice - I think, then an update to libwpd-0.8.2-1.fc3 was getting through for i386 but failing for x86_64 due to a broken dependency in a version of abiword which was present at that time. After that everything was up-to-date according to all tools when clearly it was not. Due to all of that it seems that yum is missing a "multilib check" where a transaction for a set of packages like above succeeds only if this is true for all set members. If such check can be moved down to rpmlib that would be possibly even better.
This is being handled much better with changes in how and when we install multilib packages in FC5