It seems there's an internal logic, which removes "duplicates". Once "Application" or "CL Argument" fields differ, both entries are displayed. I find this confusing.

One has to win; if you duplicate an entry and change nothing, then how would it know which one you want? You have to change something.

(In reply to Nate Graham from comment #2)
> One has to win; 
Sure, if everything were identical.

> if you duplicate an entry and change nothing, then how would
> it know which one you want? You have to change something.

Name, description and comment differ and I took this as a starting point for further changes.

Which entry should win? The older one? A random one? Why should any entry in this case "win", if I as a user have deliberately created a new entry. I expect Kicker or Kickoff or any other start menu to simply displays the items, which are to be found in KMenuEdit.

Maybe the idea originates of hiding dups arising from random installations? That would kind of make sense.

I would already be happy if KMenuEdit told me "You got another entry X, which differs only in Y. It therefore may be hidden in the startmenu unless Z is also changed".

Actually what am I saying? That was nonsense.

Basically, when you edit anything in KMenuEdit, your edits take priority over the original.

If you want to create a new item that will be displayed alongside the original, you need to change the name of the underlying .desktop file to not be the same as the original file. That's ultimately what's used for identification. When two .desktop files have the same name, the one in ~/.local/share/applications (which is where KMenuEdit puts your edits) will win.

For the case where you intentionally duplicate an item in KMenuEdit such that it's clear your intention is to show two entries, we would perhaps have it prompt you for a new filename/ID for it, so it won't be de-duplicated.