The 2014 "gnuplot-mode" has the problem of not rendering the greek symbols when asked to by babel, hence, my switch to "gnuplot-mode" 2017.
C-h v gnuplot-program reports
gnuplot-program’s value is "/usr/bin/gnuplot"
This variable may be risky if used as a file-local variable.
Documentation:
Not documented as a variable.
. . . which is correct, and, yes, as a stand-alone mode it works, i.e., it finds the gnuplot executable and renders the greek letters fine. However, when I attempt it inside a babel gnuplot code block it gives the error of not finding the executable. This is behavior I've seen when babel doesn't see a necessary mode that it requires to work with. This is my supposition/guess. As I recall, when I first tried a babel gnuplot block, it made this same complaint. Then I realized I hadn't installed the gnuplot mode. The problem went away when I installed gnuplot-mode 2014. So again, my educated guess is that babel doesn't see or want to interact with gnuplot-mode 2017, rather, it want to see gnuplot-mode 2014.
I feel like I'm beating this to death. I can simply hand-edit in the diagrams with greek letters done correctly into my org file, i.e., just not do babel gnuplot. Again, gnuplot-mode 2014 in stand-alone will do a "plot file" of the code correctly, but not a "plot buffer" strangely enough. (I'm guessing babel gnuplot wants to do a "plot buffer".) OTOH, this is a bug, i.e., no sane work-around, and we, an advanced species, shouldn't negotiate with or accommodate insects.
So what is the process of keeping babel up-to-date AFA modes interacting with their executables is concerned? Who does this? I can look at the gnuplot-modes and see if I can find anything. But I'm a total noob with big-time Elisp code.