For creating a language switch (for example in a navigation) one will use this TemplatingFunctions method (as also the travel demo does):

[#assign localizedLinks = cmsfn.localizedLinks()!]

the problem is, that the map contains the languages (Strings) as keys and not the Locale object itself. One reason is, that when Freemarker transforms the map to a hash sequence, it has trouble to use a complex object as the key (the Locale itself) when resolving by the key for an element.

The problem:
One wants not just the language name but also the Locale object itself for calling .getDisplayName() on the locale itself.
The travel demo does this really badly as delegating the resolving of the locale to the model of the project:

${model.getLocale(lang).getDisplayName()!}

This is just not usable in a light development approach...

Solution / Improvement:
Provide the possibility of resolving a language String to the Locale object via the TemplatingFunctions class:

public Locale getLocale(String language) {
        // Must catch throwing exception for returning properly Null to the Freemarker script.
        try {
            return LocaleUtils.toLocale(language);
        } catch (Exception e) {
            log.warn("Unable to resolve Locale for language {}", language, e);
        }
        return null;
}

So one can do in a navigation script the following:

${cmsfn.getLocale(lang).getDisplayName()!}

Side Topic:
I suggest to also add this method, so a Locale can directly be checked if its current:

    public boolean isCurrentLocale(Locale locale) {
        return StringUtils.equals(aggregationStateProvider.get().getLocale().toString(), locale.toString());
    }

Already existing:

    public boolean isCurrentLocale(String language) {
        return StringUtils.equals(aggregationStateProvider.get().getLocale().toString(), language);
    }