How can different packages have identical source code?

You're confusing built binary packages with the underlying source code/package that the packages were built from.

The packages you're referring to are all built from the same source code/package, mutter. You can find that easily by going to packages.ubuntu.com, searching the package you're looking at, and then refer to the "Source package" it refers to. Which in this case is mutter:

From there, however, we can check the Launchpad page for Mutter's source package and see that it builds a multitude of binary packages (built compiled source code, etc. for installation):

These descriptions describe what each package contains/installs. Focusing on the 4 packages you indicated, and using these descriptions:

• gir1.2-mutter-4 - GObject introspection data for Mutter (used by gir and GObject as libraries/data for Mutter and GObject interaction)
• libmutter-4-0 - The underlying library for the Mutter window manager. (Used for plugin development, development and compiling Mutter integrations, etc. usually)
• mutter - the actual Mutter Window Manager that uses GNOME's Window Manager Library (which is why GObject is needed)
• mutter-common - Shared Files for Mutter - usually default configuration options or items which are common to all the packages built from the source package.

What you're seeing in your package list are the built packages which originate from the same source code - each package is different items being installed after build/compile time and are used differently for different things. You can see what's in the packages themselves by downloading the individual packages and then accessing them with p7zip or the in-built Archive Manager in Ubuntu and see the differences of what each package contains that way. This said, they all originate from the same source code - they just contain different items that're being installed to the system.

Source packages and binary packages exist separately. Each source package may have multiple binary packages associated with it. This is to say that more than one binary package may be built from the same source package.

One of the common ways this happens is that you have a program, a library that the program uses to do much of its work, and the header files used to compile it and other (perhaps future) programs that use that library. They are all developed and maintained in the same source tree, which is used, with or without Debian or Ubuntu patches, to generate a source package. Then that source package is used to build separate binary packages for the program, the library, and the headers.

That's what you have here (with some other binary packages as well). You've specified different binary packages in your apt source command, but the command is downloading and unpacking the same source package.

This happens because, when you pass the a package name to apt source but there is no source package with that name, it treats it as the name of a binary package and assumes you want that binary package's corresponding source package.

---

On the main Ubuntu page on Launchpad, you can search for packages. Launchpad displays information about source packages (whilst Ubuntu Packages Search displays information about binary packages). If you search for mutter, then as Thomas Ward has said you'll find the Launchpad page for the mutter source package in Ubuntu. This is one good way to see which binary packages correspond to a source package. Near the top of that page, it says:

mutter package in Ubuntu

gir1.2-mutter-4: GObject introspection data for Mutter
libmutter-4-0: window manager library from the Mutter window manager
libmutter-4-0-dbgsym: No summary available for libmutter-4-0-dbgsym in ubuntu eoan.
libmutter-4-dev: Development files for the Mutter window manager
mutter: Example window manager using GNOME's window manager library
mutter-common: shared files for the Mutter window manager
mutter-dbgsym: debug symbols for mutter

Even when a binary package does not have the same name as the source package from which it is built, you can usually find that source package by searching on Launchpad for the binary package.

You can often know what the relationship is between a binary package and the source package used to build it by inspecting the name of the binary package:

• Binary package names that start with lib usually provide libraries of code that can be used by multiple programs (including future programs).

• Those that end in -dev provide header files, which facilitate the compilation of source code that uses the libraries.

• Those that end in -dbg or -dbgsym provide debug symbols (so even though libmutter-4-0-dbgsym doesn't currently show a summary, we know it's a debug symbol package).

• Those that end in -common tend to provide files, often data files, that reside in /usr/share. Such files are sometimes effectively code, just in a static and declarative form, but they may also provide interface translations into natural (i.e. human) languages. There's not really much limitation on what can go in such a package.

  For mutter, the -common binary package (in recent versions) contains schemas, key bindings, and documentation. One benefit of -common packages is that, because they don't typically contain any native machine code, the same package file is usually applies to all architectures. (Strictly speaking, this is the one key requirement for files placed in /usr/share.)