There are two problems here that I believe can be solved together. When I launch a program like xterm or firefox-bin, at first the launcher is the icon for the program, but then after restarting awn in the case of xterm, or just by launching firefox, the launcher is no longer the icon for the window but instead the window is shown in the normal window list with a different icon than the one I set for the launcher (as described in bug #132319). Also, when I restart AWN, the windows in the window list do not get the same icons as they had originally if the title of the window has changed (such as with xterm). My recommendation is that when trying to determine if an active process can be assigned to a launcher and when trying to determine the correct icon to use, look for any running processes with the same name as the name of the command that the launcher runs, then find any open windows belonging to that process and assign the first one to the launcher. And at the same time you can then give all the windows belonging to that process the same icon as the launcher has. In the case of windows that don't have an associated launcher, it would be a good idea to use the process name or the window's class name(s) to try to determine the proper default icon to use.
A few comments.
1) You might want to try out the taskmand/
The rest of the comments refer to the awn-core implementation. I may have a couple details wrong... it's been a little bit since I looked at it:
2) The essential problem is this. Is the icon provided by the desktop file to be used or is the icon provided by libwnck to be used? You have definite preferred behaviour... strangely others might disagree.
3) I actually tend to believe that libwnck more or less uses the method that you describe regarding using the window's class name(I could be wrong).
4) The awn core behaviour is to use libwnck to provide the icon (I think we need to bow the wisdom of the libwnck devs on this) if the process is not launched from an awn launcher (unless it's restarted of course...). If it is launched from a launcher it tries to use the icon specified in the desktop file. I think this is where you'd like to try and reassociate with launcher (see point 1 above :-) ). The core is basically just missing the attempt to associate a process launched outside of awn with a launcher.
5) Some applications make it difficult to even associate a process started from an awn launcher with the window that appears (I'm looking at you firefox).
6) Most people want the icon associated with the desktop file to be used. Some don't.
7) Applications don't necessarily really know about the desktop file spec.
7) Given a process that is launched from outside awn it is non-trivial to associate the process with the correct desktop file. Yes, it is possible to get good results. It is difficult to get good enough. See point 1 :-).
8) You are basically correct.
Summary:
The core implementation in 0.2 doesn't work as well as most people want. However, I don't think anyone has the heart to mess with the core 0.2 implementation as that code has proven to be fragile in the past... and it is at least stable at this point.
My preference would be to move all the task management out of core - and I have such an implementation available as applets and a dbus server in testing - I'm not sure how njpatel ultimately feels about the direction I have taken with my implementation :-) as there are real advantages and disadvantages. But it works, some of the applet code is currently messy(see notes above about theory/practice + different viewpoints on behaviour) but seems to be relatively stable. And you would probably find it gets closer to what you want in terms of behaviour (though you might need to use the regex whitelisting feature on a few things to get the awn restart working the way you would like).