U-Boot's extlinux.conf label generation facilities (defined in meta/classes/uboot-extlinux-config.bbclass) generate incorrect results under some circumstances.

When using non-default labels (e.g. UBOOT_EXTLINUX_LABELS = "default", replacing the default value of "linux"), user-supplied label descriptions are ignored (e.g. UBOOT_EXTLINUX_MENU_DESCRIPTION_default = "Foo" will always be ignored in favor of the default value supplied in UBOOT_EXTLINUX_MENU_DESCRIPTION).

This behavior results from the class using OVERRIDES to support label-specific definitions, and the default label using an identifier that corresponds to a common ${OS} value, which by default appears in OVERRIDES.

For example:

UBOOT_EXTLINUX_LABELS = "default"
UBOOT_EXTLINUX_MENU_DESCRIPTION = "Foo"

During processing of the "default" label, the OVERRIDES will be updated from "${OS}:..." to "default:${OS}:...".  Because "linux" will be the most common value for ${OS} in this situation, it will frequently be evaluated as "default:linux:...".

Later, when writing out the entries for that label, it will request the value of "UBOOT_EXTLINUX_MENU_DESCRIPTION", at which point it will iterate through the OVERRIDES list, first processing the value for UBOOT_EXTLINUX_MENU_DESCRIPTION_default, then in a later iteration finding UBOOT_EXTLINUX_MENU_DESCRIPTION_linux, and using that value instead.

The OVERRIDE precedence rules essentially guarantee that the default value assigned to the _linux variable will supercede any user-supplied values for any and all labels.

I see three possible fixes:
1. change the provided label from "linux" to "default" or "primary" or similar, something that's not a commonly used value in OVERRIDES.  If using this solution, documentation changes should probably be made to discourage using OS-, DISTRO-, or MACHINE-related values for labels.
2. in the local copy of the dictionary used for generating label entries, clear out all pre-existing values of OVERRIDES
3. instead of prepending the label to the list of OVERRIDES, append the label to the list, giving it the highest precedence (although properly speaking it should be inserted before forcevariable, if it exists, giving it the second-highest priority).

A related issue exists where values defined for the first label shadow values defined for subsequent labels (when multiple labels are defined), because the dictionary gets re-used between iterations over the labels, and the newly-added label OVERRIDE has lower precedence than the previous labels, which are still present in the OVERRIDES list.

This related issue would be solved by options #2 and #3 above, although solution #2 is likely to result in surprising results where values not set for one label would essentially default to the value used for the previous label.

Alternatively, solution #1 combined with moving the dictionary copy into the loop, giving each label iteration a fresh copy of OVERRIDES (along with everything else) would also solve this issue.