There is a variant of dedup.debian.net, that analyzes binary packages for Multi-Arch properties. From the analysis a number of hints are generated and fed into tracker.debian.org. Below you can find explanations for why hints are emitted and what they mean in detail. The source lives in a branch of dedup.debian.net called multiarchhints. If in doubt, contact email@example.com or #multiarch on the OFTC IRC network.
The package in question is marked Multi-Arch: same, but has conflicting versions of at least one file for different architectures. The hint tells the filename (or the number of filenames) and the architectures (or number of architectures) in question. The easiest way to fix is to remove the Multi-Arch: same declaration, but often enough it can be fixed by moving the offending files to per-architecture locations (typically /usr/lib/$(DEB_HOST_MULTIARCH)/). For *-dev packages, the Multi-Arch: same capability often is not critical and removing is a good initial measure.
In some cases, the difference is unintentional and can be resolved. You can download the relevant binary packages, extract them using dpkg-deb -x to a directory and compare the affected files using diffoscope. Sometimes, the difference is simply due to some build tool being versioned differently for different builds. Reuploading or binNMUing the unmodified package can resolve this.
set Multi-Arch: foreign
The package in question is Architecture: all, does not contain any maintainer scripts and does not have any dependencies on architecture-dependent packages. Thus there is no way for it to expose architecture-specific interfaces and marking it Multi-Arch: foreign usually is safe. The hint can be wrong when other metadata is wrong already (e.g. a dependency is wrongly marked Multi-Arch: foreign). Care must be taken when updating the package. When it is switched to Architecture: any or maintainer scripts or dependencies are added, the marking should be reevaluated.
Note that even though Architecture: all and Multi-Arch: foreign may look like similar concepts, they are not. The former means that the same binary package can be installed on different architectures. Yet, after installation such packages are treated as if they were "native" architecture (by definition the architecture of the dpkg package) packages. Thus Architecture: all packages cannot satisfy dependencies from other architectures without being marked Multi-Arch foreign.
set Multi-Arch: same
The package in question is Architecture: any, does not contain any maintainer scripts and for any pair of architectures, the common files have equal content. Thus it should be safe to mark the package Multi-Arch: same (by placing that field in the corresponding debian/control binary package section). Care must be taken when updating the package. If maintainer scripts are added, they need to handle configuring the package multiple times or the Multi-Arch: same tag must be removed. Also content changes can result in Multi-Arch: same becoming inappropriate. Some packages (e.g. libblas-common) exist to prevent co-installation of other packages and must not follow this hint either.
annotate a dependency with :any
The package in question is Architecture: all, does not contain any maintainer scripts and it has only one dependency on an architecture-dependent package, which happens to be marked Multi-Arch: allowed. Usually the relevant dependency is an interpreter such as perl, python or ruby and other dependencies on packages marked Multi-Arch: foreign can exist. Since the package in question is architecture-independent, it cannot use the interpreter in an architecture-specific way (e.g. via extension modules) and thus it usually does not require a particular architecture. Thus it is suggested to annotate the relevant dependency with :any. The hint can be wrong when other metadata is wrong already (e.g. a dependency is wrongly marked Multi-Arch: foreign or Multi-Arch: allowed). Care must be taken when updating the package. When dependencies are added (e.g. on extension modules), the annotation can become wrong and may have to be removed.
convert to Architecture: all
The package in question is Architecture: any, does not contain any maintainer scripts or dependencies on architecture-dependent packages and the contents of the package does not differ for any pair of architectures. Since only release architectures are considered, the analysis may miss differences and wrongly report a package. It can also be wrongly emitted when other metadata is wrong already (e.g. a dependency is wrongly marked Multi-Arch: foreign). Care must be taken when converting packages from Architecture: any to Architecture: all. The conversion can make the package binNMU-unsafe if /usr/share/doc/thepackage is a symbolic link or other packages link docs to it for instance. Common sense is required for deciding whether the conversion really is safe. When doing the conversion, the package should be marked Multi-Arch: foreign for the reasons given in the "set Multi-Arch: foreign" section.
Multi-Arch: foreign library
The package in question is Architecture: any, marked Multi-Arch: foreign, contains a shared library in a public library search path and does not contain any public executables. Most likely, its Multi-Arch: foreign marking is wrong. Shared libraries never provide an architecture-independent interface. Some shared libraries exist as plugins to a program, but this package does not contain any programs. If you happen to find such a package where Multi-Arch: foreign is correct, please edit this page and note it here. Otherwise remove the Multi-Arch line from this binary package.
requires Multi-Arch interpreter workaround
The package in question is known to expose an architecture-dependent dependency (for instance, because it is a rust library) has such an architecture-dependent dependency and is currently Architecture: all and Multi-Arch: foreign. As such, it requires the Multi-Arch interpreter workaround, which means that the package should be converted to Architecture: any and Multi-Arch: same.