Actions are one of the most important parts of ROS1 but they always felt a bit like an afterthought
As one of the original developers of actionlib, I can most definitely tell you that actionlib was an afterthought. Actionlib came much later (6-12 months-ish) than the development of topics & services. Eitan Marder-Eppstein and I weren’t sure whether actionlib would be useful beyond just move_base & the pr2_calibration stack, and there was a broader design decision to not force a complex, seemingly extraneous feature like actions to be part of the core ROS APIs, thus increasing the complexity of porting ROS to a new language. In hindsight, actions turned out to be pretty important to the ROS ecosystem 
Design Feedback
- I totally understand the benefits of keeping much of the internals of actionlib the same between ROS1 & ROS2 (ease of portability, easy of interoperability, etc). However, if you are considering making more drastic changes (which may be necessary given some of the additional features in the design doc), I’d seriously consider redefining the client state machine. As stands, implementing a SimpleActionClient is unnecessarily complex, since the SimpleActionClient states are not a straight reduction of the ActionClient states. This means that the simple action client needs to know about both the current action client state and the previous action client state in order to compute the current simple action client state (see diagram on the wiki actionlib/DetailedDescription - ROS Wiki).
Contributing
- The Virtana team (www.virtanatech.com) has several early career roboticists who’d love to get more open source contributions under their belts. Once the ROS2 actionlib team gets more of the implementation & design firmed up, we’d love to pitch-in in places that might fit the “good first issue” label.