need to be sure that the desired behaviour is well thought out.

When I reviewed this component, the behaviour seemed relevant since it had been determined that we would be taking advantage of the <select> tag behaviour in the device and desktop browsers.
Since cross-browser implementation meant that we would only be able to count no the 'onchange" event, we would need to reset after each use of this component and that was deemed acceptable at this time. Is that not still the case?
Looking at overriding this behaviour and having the "Select" option keeping the menu open, would mean that the user could never close this popup selection unless they chose one of the other selection options. This could be a problem if they did not really want to trigger one of those events.
By allowing the Select option to close the popup, they always have a "safe" out of the component.

My understanding was that they users had a valid use-case to be abel to click on the same option twice in a row and have the corresponding jsf eventListener get triggered, so no work was put into managing the events triggered (although Select should not trigger a request and testing to ensure it does not.

Although this is a customer-requested feature, it does sound unusual for a menu component. This should likely be a separate component or an application feature using a popup. It is not targeted for 1.1 Final.