The left side of the figure shows the pre-OS usage of the information, such as a PC's 'setup/browser' application. The right hand side shows how this information can be ascertained via a pointer in the EFI_SYSTEM_TABLE to view the information at runtime. It is this 'export' behavior, a requiremetn of the UEFI specification, that the mailing list patch at the top wanted to make optional via the firmware build.

"OEMs typically have their own keywords and
namespaces that they use when interacting with target
platforms. Given that, a standard method to interact
with a target platform might be one which leverages the
syntax established by DMTF’s SMASH CLP [3]. The
typical CIM_BIOSAttribute associated with CLP expresses
configuration data by using a “:”
syntax.
Given the previous example, one can imagine that a
UEFI-based syntax could be expressed by having the xi-UEFI
language equivalent value replace the
value and the value would be UEFI"The The x-UEFI configuration language is now a reality. The latest keywords can now be found at http://uefi.org/confignamespace. This list should grow over time as more configuration data emerges based upon new platform technologies, features in the UEFI and other industry standards, etc.

This type of facility helps provide infrastructure to provide visibility into 'Is Features XYZ enabled." A common instance of this is virtualization technology, hyper threading, and other art managed by the platform.Going forward, I can imagine OS viewer utilities, maybe /dev/hii in Linux and an associated Microsoft Windows interface, to exposing this information. The EDKII community on tianocore.org ought to investigate some simple shell applications to export the information, too.