I don't know the source code, but seems when $HOME/Documents exists then that will always be the choice in kdialog regardless of what I set elsewhere. In this specific test, changing KControl:Paths did update user-dirs.dir but Kate/Kwrite/Kedit all wanted to open in $HOME/Documents.
Manually deleting $HOME/Documents then got the editors not to look in $HOME/Documents but they all looked in $HOME. Even when I used KControl to change to a directory outside $HOME, they all three would not look in that new location.
All of this happens after logging out and deleting the ksycoca cache too. The problem then seems to be coding and not caching, even if that was possible.
I would look in the code to see whether the existence of $HOME/Documents mistakenly overrides user-dirs.dir. The second glitch is why the apps don't correctly look in user-dirs.dir or don't honor that location.
I know this worked at one time. I don't remember how long ago. :(
The pattern seems to be this:
* The contents of user-dirs.dirs is ignored in kdialog.
* If $HOME/Documents exists, then always use $HOME/Documents as the "documents" path in kdialog.
* If $HOME/Documents does not exist, then use $HOME as the "documents" path in kdialog.
* Changing the URL in the psuedo device icon "My Documents" has no effect on user-dirs.dirs.
* Changing the "documents" path through KControl or editing user-dirs.dirs is never reflected in "My Documents" icon.
Darrell