Unfortunately, it seems like things don't quite work the way you would like them to.
ein:notebook-multilang-mode is simply a major mode. That means a lot of things, but here it basically defines fontification (i.e. "syntax highlighting"). You can see that from the source code, available via help (
C-h f ein:notebook-multilang-mode). The docstring for my version of
ein (likely outdated) also happens to state,
A mode for fontifying multiple languages.
What this means is that each cell will receive different highlighting based on the language. This is different from each cell providing a different environment according to the language.
The challenge is that Emacs generally works on a per buffer basis. That's the most common and natural unit to work with from an implementation standpoint. The modes which dictate the behaviors for Python, R, or Markdown need a way to know when and how to apply the rules (such as indentation, identifying keywords, interaction with an interpreter, etc.) that make, say, R mode different from Python mode.
It's natural to envision an
ein cell also being aware of the corresponding language mode. (This is what I understand your question to be about.) However, from an implementation perspective, it's not clear how that would be accomplished. It's an interesting problem. You have to answer questions like, "How will binding X work if the behavior might need to differ on line 14 versus line 355?" For example, if you have both R and Python cells, a binding might reach out to an interpreter. How would a given cell know which interpreter to contact? Are instances between Python cells associated?
All of this could be accomplished; it just doesn't seem like
ein has done so1. There are packages such as
Mu Ma Mo whose goals are multiple modes operating at the sub-buffer level. Maybe one of those could be used to implement such functionality.
I'd be remiss, however, if I didn't mention Org babel. It provides the ability to do literate programming, with multiple, concurrent languages and the ability to specify which interpreter (i.e. "kernel") to use for each block (i.e, "cell"), as well as export to HTML, PDF, Latex, etc. Each source block can be expanded to a separate buffer whose mode is automatically set to the appropriate language. You can also "tangle" (extract) the code blocks into a single .py or .r file. And so on. I understand if you're bound to Jupyter Notebooks, though.
1 Maybe you could implement it. That would be a cool contribution!