I don't have research on it, but some experience. In this case it was teaching functional to those with some other background as part of a language principles course.
I'm a terrible Lisp/Scheme programmer so I was as outside my comfort zone as the students were. I did two things. First, I used Standard ML instead of Scheme. I can program effectively in ML, though I realize that the concrete syntax is a crutch. I need that crutch but also used it to teach students who were used to programming with such actual keywords and such. Thus, I used syntax to keep them closer to their own comfort zone.
The second thing, was comfort zone breaking. I taught by focusing specifically on the functional thought process, rather than teaching the language as if it were something fresh. "This is how you have to conceptualize the program!" "Yes, they call them variables, but they are really constants! Deal with it." "You are used to thinking this way. Now you need to think that way."
Functional programs also have a number of design patterns that are pretty ubiquitous. These patterns are part of the programmer's tool kit because if you aren't careful you can write some terrifically inefficient programs with lists if you don't know the patterns (tricks, if you will). An example is appending one list to another. It is a linear time problem, but a naive program is probably quadratic. This is probably hard at first sight for any new functional programming novice, but what is obvious to an imperative programmer just doesn't work efficiently. So, the instructor needs to know those patterns as much as they know the paradigm.
A pedagogical trick you can use, especially for manipulating lists, is to simulate the operations/algorithms using students as values and building up a list (a lineup of students). They walk through an algorithm and see how values are manipulated.
But, teaching novices with no background at all (do they still exist?) is a bit simpler. Start with simple things that build confidence for more complex things, never leaving the paradigm.
But as response to your observation that it is probably different teaching novices and others is yes. Otherwise the experienced programmers will assume too much that turns out to be wrong. The novices have fewer assumptions to make.
I'm pretty sure I've said this before here, but paradigms (consistent ways of thinking) are difficult to change. My go-to example is the change over from highly trained knights on horseback, typically noblemen, to mass armies of lightly trained peasant infantry. The Battle of Agincourt was in 1415 and proved decisively that knights were obsolete as the French army (and much of the nobility) was destroyed by an army of English longbowmen. But in about 1500, Henry VIII (1491-1547) started his training as a knight. He was the last English king who went through the complete training. So, it took about 100 years to recognize that a paradigm had died and been replaced with another. Even in England, which won at Agincourt. Henry's armor (and I think that of his horse) can be seen in the White Tower within the Tower of London.
