I agree it can be useful in some cases to display the language, but I'm not sure this option would be that useful in Docusaurus for a few reasons:

• Afaik only you requested it so far so we don't really know if there's user traction
• It probably doesn't make sense to apply it by default for all languages, we need flexibility
• We need a way to display "clean" language names, maybe not just "md" or "js"
• It can be implemented in userland with swizzle or a remark plugin with greater flexibility

Considering it can be implemented in userland easily, I'd prefer to see production implementations in userland first, proving that there's real traction, before adding a first-class option in Docusaurus. Once we have a few production sites using it, only then it's worth adding to Docusaurus.

In general, I prefer focusing on shipping primitives that allow you to compose those primitives the way you want with great flexibility.

We have md code language, and we have md code meta string support for a title attribute. You can achieve what you want by combining these 2 primitives using your own custom code and custom rules. Here's a remark plugin example:

const mapping = {
  js: "JavaScript",
  ts: "TypeScript",
}

function languageAsTitleRemarkPlugin() {
  return async (root) => {
    const {visit} = await import('unist-util-visit');
    visit(root, 'code', (node) => {
      if (!node.meta && mapping[node.lang]) {
        node.meta = `title="${mapping[node.lang]}"`;
      }
    });
  };
}

It's more code, but also more flexible. Adding a useLanguageAsTitle themeConfig would only be an unflexible shortcut doing exactly the same. I'd prefer to only add such shortcuts once traction is proven in the real world, and that we can compare how implementations converge to find out the best opinionated API.

Does it make sense?

Thanks the in depth explanation! I'll try the plugin approach and report back.