In KWin we also ensure that the desktopFile ends with .desktop prior to passing to KDesktopFile:

QString desktopFile = QString::fromUtf8(m_desktopFileName);
if (!desktopFile.endsWith(QLatin1String(".desktop"))) {
    desktopFile.append(QLatin1String(".desktop"));
}

The desktoFileName is without the .desktop suffix.

In KWin we also ensure that the desktopFile ends with .desktop prior to passing to KDesktopFile

This shouldn't be necessary. "Passing to KDesktopFile" in this code's case is calling KDesktopFile::isDesktopFile, which is documented to do the following:

"The check is performed looking at the file extension (the file is not opened). Currently, the only valid extension is ".desktop". "

I.e. checking for the extension isn't necessary, that's what isDesktopFile() is doing. Basically, we try to find a KService first, and if that fails we check if it's a .desktop file and whether it exists, then use it.

exactly. So if you get a name which does not have the .desktop file extension it won't be used.

But that seems sensible. The only time the app should set the prop to something that doesn't end with .desktop, it would be a "system menu id" related to a .desktop file that KService can locate. If KService can't find anything, I expect (and check for) the prop value to be an absolute path to a .desktop file outside of system location and include the extension. If that's not the case, something is fishy - the app is likely not well-behaved and it seems smarter to use the general heuristic than trying to fix up a broken path value.

Also quoting KWS:

"If the application's desktop file name is not at a standard location it should be the full path to the desktop file name (e.g. "/opt/kde/share/org.kde.foo.desktop")."

What value do you see in being lenient and fixing up a broken absolute path?

In KWin we had needed to add the .desktop - this is just passing on experience. Do with this experience what you want. For my part I don't trust our application developers to pass in a correct ID. This is a very easy way to fix it from our side.

I'll grudgingly add it, although something about modifying absolute paths feels really unsettling to me.