"First you are confusing two different aspects of Wine. ...  If you don't like the apps in the current package you can always compile it yourself."

Yeah, if I had even more free time I could compile my own distrobution. But that's not the point of a bug-report on Ubuntu is it? That would be a nice 'go away' response to any bug-report. 

"Again, this is a packaging issue. If they are not useful then they should not be part of the package in order to save space. I fail to see any difference between winefile and the Java Web Start or regedit and the Java control utils."

Well winefile may have its uses, but wine-mine and wine-notepad are _nothing_ like Java Web Start, or Java Control Utils. In line of that analogy, Java would be installing eclips, and some java-games, not to mention the java-docs including a desktop shortcut to them. Not to mention the fact that java programs actually integrate into their desktop environment. They don't need a special file-browser. They don't need a special registry editor. 

You bring up the technical point of view that it is a packaging issue. But I don't think that space is the issue here: it's the clutter of uniting two worlds into one menu. Two worlds that do not integrate. Wine does not respect the gnome nor kde file-associations. Visa versa they don't respect the wine file associations.

The fact is, although we _want_ wine to be like Java, it is not. To run steam.exe on ubuntu we get 8 links to manage all that. We end up with two text-editors instead of just one. (confusing). We end up with two file-browsers instead of just one (confusing). We end up with two package-managers (instead of just one). We end up with two minesweeper games. How the hell did minesweeper become a dependency of steam.exe? Then we see the light:

*It's a desktop-environment*

It has its own tools, its own file-browser, its own package-management. Wether we like it or not, its a completely separate world. We don't want to use wine-notepad to open files on our gnome-desktop. We don't want wine-file to browse our normal home-directory. Unfortunately we may need those tools. But because it is a separate world, it should be in one united menu. 

"Change requests to Wine's app install behavior need to be made upstream at bugs.winehq.org"
"I don't think that is possible automatically. Wine can't determine what kind of Windows application it installs. There is no data in the apps that indicates a category. Either it would have to look it up in a table or ask the user."

Exactly. So we have to have a wine menu anyway! The menu is already there!
Yet it does not contain all wine links. Just some of them. The wine world has its own little planet, with its own rules, its own menu, but certain stuff is located on the gnome/kde planet. Isn't the situation confusing enough without that mess?

"The basis for their menu locations is the same as for Java."

No it's not! Java does not create its own java menu for user installed java programs.
It does not require its own file-manager. It does not require its own text-editor. The help files concerning java are part of the standard ubuntu help system. Java programs respect the file-associations of the desktop-environment. It puts programs into the correct category. Java programs do not mangle the path and filenames of files on your hardrive. It does not need a virtual drive like wine does.

It's nothing like Java. 

But back to the fact that wine already adds its own menu anyway:
Now to add to the inconsistency: we put certain wine stuff in other menu's.
Stuff like file-managers, package management. But is not general package-management. It's not a general file-managers. It's not a general package-managers. It all deals only with the wine-world.

Now when we already have this menu anyway, why not put _all_ wine stuff there? 
Seems a whole lot less confusing to me.
It emphasizes this the separation between the two worlds. The separation users will experience anyway. 

"Using winefile is an option, not a requirement. I find it useful because it presents a Windows-like view of the file system which is more familiar to n00bs. And as I stated previously it's also useful for launching Windows exe files when the file association in Nautilus is broken by user error."

We don't install konqueror to open a mp3 with amarok, just because nautilus file-associates might have been changed by the user! When you install amarok (and with that kde-support) you don't install konqueror, so why do we install wine-file when we just want to install wine-support? Because amarok actually integrates into the system, even when its a kde app. Wine apps do not. 

I actually understand why somebody would prefer wine-file to force something to open with a windows program.
This is not the point. People would be less annoyed by all those desktop links if they are just united into one menu. When to use which file manager would be clear.

I still prefer to use nautilus for everything and I think its important people can easily use nautilus/konqueror to access their wine-drives. Creating a menu link to that as Darkegel suggested would be a perfect solution to that particular problem. But this menu link too should be in that one and only wine-menu.

Again, i dont' want to offend you. You do a great job and take the unexperienced user into consideration, these are all minor issues compared to the previous situation of having no desktop-links. Yet, it currently just feels messy and confusing. Like installing both kde and gnome. You end up with a messy menu. About this too are bug-reports, and scripts that clean everything up. (they put the 50+ kde apps in a kde menu on gnome and the 50+ gnome apps in a gnome menu on kde). 

I really don't think i'm alone in thinking that in the particular case of wine, one united menu would be the way to go. Esspecially when there already is a wine menu containing the wine-installed-programs.