These styles look great; I would just recommend sticking to all snake-case or all camel-case for consistency, instead of mixing them.

So, that's what confuses me about BEM. I like doing, for example, .sum-share-panel where .sum means Sharing UI Menu. How do I differentiate between "this is the namespace" and "this is the component"? I reserved hyphen-case for states (.sharing-ui-menu__ListWrapper-is-open)

Hmmm... I think you should try treating the component as the namespace. For example, shareMenu:

/**
 * The shareMenu has a lot of children, indicated by the indented classes
 * below it.
 */
.shareMenu {
  text-align: center;
  display: inline-block;
  vertical-align: top;
}

  /**
   * This single indent indicates the child relationship. This class is tightly
   * coupled to the shareMenu. It literally can't be used outside of the
   * parent element... it just wouldn't make any sense in the UI. It has
   * the double-undescores because the shareMenu can't work without it either.
   */
  .shareMenu__list {
    display: block;
    margin: 0;
    padding: 0;
  }

    /**
     * This shareMenuItem is indented beneath the list for the same reason.
     * Its naming pattern changes because it's going to have child elements
     * and have something like .shareMenu__list__item__label__text will become
     * too verbose. This component has a little more identity that shareMenu__list
     * so it seems like a good place to re-establish its role as a parent of
     * child components, via its name.
     */
    .shareMenuItem {
      display: inline-block;
      text-align: center;
      padding: 10px;
    }

      .shareMenuItem__icon {
        display: block;
        font-size: 28px;
      }

/**
 * This is non-indented, because it's not a child of shareMenu. They're related
 * via the 'share' in their name, but it's clear they have different roles and
 * their relationship is distant, not direct.
 */
.sharePanel {
  display: inline-block;
  vertical-align: top;
  padding: 10px;
  width: ~"calc(100% - 150px)";
}

Want to Zoom about this tomorrow?

I didn't notice this earlier, but sharing a styles declaration really tightly couples these two classes. This is great if there is some commonality or cohesion from the perspective of their role as UI components. But if it's just coincidence that .sharing-ui-menu__ListWrapper and .sharing-ui-menu__SharePanel share styles then I think it's better to duplicate the styles and split the classes apart. I think this will improve maintainability because then they can be changed independently without affecting one another.

That's on purpose, I usually do this when I have two elements that are inlined next to each other

I feel like we need a strong grip on what we want to do when it comes to naming classes.

As it stands, we're not going for a "lax" approach such as "just define a unique component namespace and do whatever you want in there", as in .abc-list, .abc-list-has-item, .abc-item, etc.

Having both a namespace, that's not clearly delimited, - because you could have say .shareButton and .shareButtonText - and at the same time having component names, is bound to be confusing.

Per Zoom convo:

• We'll use component names as namespaces (e.g. shareMenu) instead of abbreviated prefixes (e.g. sui-) because they're a little more concrete.
• We'll use indentation to indicate parent-child relationships.
• We'll change the pattern of state classes to use the component name first (I'll update the CSS style guide to reflect this).
• We'll avoid changing components based on context because this makes the styles less maintainable. We'll also use component-specific state classes for the same reason.

We may want to keep the is part of state classes, so that they are immediately indicative of component state. Thoughts?

Totally agree. Let's use the pattern you gave here: https://github.com/elastic/kibana-ui-framework/pull/11/files#r72156938