Hey! Sorry for the late reply. And thank you very much for such a detailed feedback 
I really needed perspectives other than my own.
The only indication for inputting code is textual instruction. Paired with the default text input box from elm-ui, the sign of interaction is indeed pretty weak. I wanted to implement what you suggested, the inline code editing similar to https://www.haskell.org/. However I seriously lacked the CSS skill to do anything outside of elm-ui. If I catch up with that, it will probably solve the ambiguity of which code is being edited, the inadequate vertical space, and help indicate interaction, maybe with some other help.
My initial plan about where I’m taking this is likely a blog series on implementing a full emoji solution, including parsing, displaying, emoji picker and so on. However, as shown from what I’ve edited in the “Updates” section of this post, I didn’t know people can directly type emoji already 
I haven’t planned much yet, but if I’m moving forward with this series, I probably need to think about and address the use cases first.
The concept and implementation of interactive guide can certainly be used on new topics as well. Although as much as I’d like it, it seems dangerous to replicate the idea on a backend language? User can do a lot more with a backend language, then a frontend one. I could limit input length, but I worry if someone may still find a short, clever piece of backend code to run and compromise the server.