GNOME Volume Control mockups:
So, many comments and help on my mockups. Apparently, they help. ;-). Glad people like them.

So, some terminology. The user doesn't need to know them, but just so people know. A single soundcard representation is called an element (e.g. SB!Live [ALSA]). A single sound particle in an element (e.g. line-in) is called a track. A single slider is called a channel (left, right). Mute turns off sound on your speakers and/or headphone when selected. Record turns on sound capture from input tracks such as line-in. Tracks with record turned on will be captured when read()ing from the device. Other tracks will be ignored. Lock groups individual channels in a track together, so if I change the volume on one channel, all other channels in the same track will move to the same value as well. All UI-visible aspects of this are explained in the manual (Help -> Contents), kindly provided by Sun Microsystems.
Oh, ALSA (in its API) calls tracks elements. Elements are called handles. Nevermind the consequence.

Tybstar, on IRC, was the first to give some helpful comments, mostly related to spacing in the window between sliders, between tracks, etc. Mostly some finetuning of the window mockups to the UI guidelines and the HIG. Thanks for that, will work on that. Got some UI tips from Havoc as well, in his p.g.o post, will look at those as well, most sound good. This is stuff like layout, naming and tooltips-on-sliders.

Benjamin (on IRC) and Havoc (on p.g.o) gave some more terminological comments. Nice to know that people care about that. That's somewhat hard, though, not in the last place because the kernel has no single interface that is suited for that job. In other words, it's gonna be incredibly hard, if not completely impossible, to acquire all the necessary information that is needed to get g-v-c up to the level that they propose. I'm also not sure if it's what end users expect. Other comments are very helpful, though, so let's see about some of those in detail.

Volume Applet, GNOME Volume Control and Applications: the volume applet is supposed to be the fast'n'simple accessor for volume control. Any simple control to your master volume should be done via that applet, and any user should have that exposed on its menubar. GStreamer's mixer API (more on wording later) has a MASTER_TRACK flag somewhere to see which of the tracks is the master track. GNOME Volume Control is not for any simple stuff. Benjamin proposed a "simple" version where I can change "output volume", "input volume" and where I can manually show tracks if wished for. This is, according to one of my housemates, similar to what Windows XP does.
This is not a good idea, imho. It's practically impossible and/or unwanted for 2 reasons. The first is that we downgrade any user to the lowest common denominator of all types of users, and give him no more control (by default) then this. Benjamin replied that advanced users would use alsamixer anyway. Well, alsamixer is not part of Red Hat, Fedora or SuSE's default installs and shouldn't be an end user app because it's commandline only. GNOME should have a similar "alternative" for its power users. The second reason is that, at least for inputs, we'd be changing all volumes to one value. The effect of this is best explained by telling what it does on inputs. Setting PCM and Volume tracks both to 90% will result in much more noise at the same audible loudness then when Volume is set to 80% and PCM to 100%. This is hardware imperfection and cannot be fixed or detected in software. For simple stuff, look at the Applet. For complicated stuff, use the Volume Control. Changing the CD playback volume or just changing volume (Joe User vs. Joe Hacker) are both simple and valid use cases...
Applications will always show just the one or two controls that they are interested in. I don't think that means we should leave them out from the main volume control applications. Windows doesn't do that either, neither does Mac OS X.
What I *am* planning on is to hide a lot of those tracks by default. Particularly all of the options and quite some of the more complicated input/output tracks. There'll be a preferences window (returning from pre-2.4 days) to hide/show tracks as the user wishes, but the default should make sense for a default user.
I'm definately not gonna add an advanced and simple mode, like Nautilus-1.x or Windows XP. It's not right (tm).

Volume Control vs. Mixer: naming confusion. I called it mixer in the beginning, and felt bad about that later on. I decided to call everything in the UI Volume Control from now on. Mixer is too technical.

Signals: or, well, rather, GNOME Volume Control updating sliders' values if I change volume in the Volume Applet. Will be worked on shortly, right after the UI is fixed.

Menubar: well, since we'll re-introduce the preferences screen, and the Help -> Contents explains some terms used in the UI (should I use icons like the ones from the GIMP instead?), I guess we can't really remove this just yet.

Headphone vs. Speaker Volume: not possible, I'm affraid. Nice idea, but there's no way to get the required information from the kernel.

So, in the end, some hints are useful, some are debatable and some are - at least now - impossible. I'll try to find the golden middle road. Please give me more feedback, it's very useful and makes me realize a lot of details and all that about UI development - good thing!

Edit!
Apparently, all sort of people sent me emails as well, I forgot to read my email for the past few days because I went to PS1 (yay for parties in Queens!) yesterday. I'll read those too, I promise!