In a JUCE plugin, you can use the AudioChannelSet class to determine the meaning of each channel. You can use AudioProcessor::getOffsetInBusBufferForAbsoluteChannelIndex to find the bus and bus-channel corresponding to a specific absolute input/output channel. From there, you can use AudioProcessor::getBus to return the bus at that index, then Bus::getCurrentLayout to find the channel layout applied to that bus. Finally, you can use AudioChannelSet::getTypeOfChannel to find the type (left, right, center, LFE etc.) of a specific channel on the bus. This is the sort of technique you should probably be using to label and order your meters.
The above procedure should be portable across all plugin formats and hosts. However, it does require that the host correctly advertises its channel layouts. As discussed in this thread, newer versions of Logic don’t seem to accurately report their channel layouts, which makes it difficult for JUCE to remap the channels correctly into the “JUCE channel order”.
The way this is supposed to work is that the plugin can advertise support for specific layouts, and the host can also request to use specific layouts. Both sides should agree on a layout before processing begins. The purpose of the constants mentioned above (kAudioChannelLayoutTag_Logic_Atmos_7_1_4_A etc.) is to describe the layout of channels on the bus. In the case of the 7.1.4 A and B layouts, these have different channel orderings. Because there are (at least) two different possible 7.1.4 layouts, it’s very important that the host and the client both agree on which layout they are going to use!
The problem that I was seeing in testing is that Logic picks a certain layout, but it doesn’t seem to communicate this layout to the plugin, or respect the plugin’s requests to use a specific layout. In addition, the chosen layout seemed to depend on the architecture of the host.