@DavidTC: You are correct when you say that Kovid is the person who will make any decisions here. That said ...
I cannot imagine that he would agree to change the semantics of save/send templates in the way you describe (don't remove slashes). Doing so would probably break sending some books for every calibre user that uses save to disk/send to device, and that is millions of people. Consider what would happen if an author or a title contains a slash: seemingly random new directories would be created. Note that save/send templates existed long before I implemented the template language some 5 years ago. The decision was made way back then not to break existing templates.
I don't see any issues around template functions. They operate on their input, whatever that is. The semantics of the functions don't change.
The function "field" returns the "formatted" value (a "processed" value) in all contexts. When in the save/send context, that value will have slashes removed (except for composites), "title" becomes "title_sort" unless a tweak is set, custom number columns are unformatted, etc. The function "raw_field" returns the underlying value without any processing. For example, if the title of a book is "The Horror" then in save/send context {title} and a use of "field" will return the title sort "Horror, The" while "raw_field" will return "The Horror". In the GUI context, "{title}" returns the title, not the title_sort.
In your case, use this
Template Program Mode template item
Code:
{:'raw_field('#savepath')'}
to get the value without the "remove slash" processing.