I'm not sure when the definition of the variable org-babel-load-languages changed, but I think we may need to consider either reverting it or making some other adjustment.
Originally, this variable was an alist of languages and a boolean indicating whether the language should be loaded e.g. '((emacs-lisp . t) (clojure . t) (sql . nil)) which would load emacs-lisp and clojure, but not sql. However, the default value for the variable now appears to just be '((emacs-lisp . t)) This has two consequences. The first is that the doc string for the variable is now incorrect. It states in part "This list can be used to load support for any of the languages below. " There are no languages listed below. This also leads to the next issue. How does a user know what languages are supported and can be enabled? Previously, you had a list of all the supported built-in languages - most of which would be disabled (nil) by default. However, this did make it easy to know what languages are supported - you could use customize to change the flag from nil to t (or copy the default into your init file and modify appropriately. Now it doesn't seem to be as clear. Note also that the doc string refers to the variable as a list, when it is actually an alist (association list). This could be confusing, especially for new users. The doc string probably should describe the format more precisely i.e the CAR of each con cell making up the alist is a language syumbol e.g. emacs-lisp and the CDR is a boolean that will be 't if the language is to be loaded or nil otherwise. . Should the default value for this variable be a list of all the supported babel languages which are bundled with emacs, all of which set to 'nil' to disable them except emacs-lisp (to maintain existing semantics, though I do wonder if we should also enable eshell given we enable emacs-lisp by default because all necessary dependencies are provided by emacs, as is the case with eshell)? The alternative is to update the doc string. I guess we could reference the URL to the worg page which lists supported languages. However, I'm not sure this is a great solution from a usability perspective, particularly for new org mode users.
