1/ Theoretically only actions can call APIs, so there are two cases, either there is no reason to not send an email, then you can proceed directly and report the result to the model with a proposal, or your action proposes to send an email, in which case the model will evaluate whether the email can be sent in which case the state should change such that the next-action-predicate will trigger the sendEmail action. If sending the email is synchronous with respect to the state of the system, it's ok to take a short cut and do it in the model, as long as you can be garanteed that no other action will be processed in the mean time.
2/ Actions can propose to any number of models, model and actions are entirely decoupled, I have expressed before that 3rd parties could propose to the model with an auth token .
3/ Logically an action cannot depend on another action, this maybe what you observe, but only the model and NAP should correlate/orchestrate the execution of the second action. Now for code reuse, one can functionally decompose an action into two functions which proposal could be added or even manipulated but logically the flow Action -> Mutation -> Action cannot be tempered with, only optimized.
4/ SAM is reactive, you never communicate "back", only forward. Action -> Model -> State Representation -> NAP -> Action ...
The model can of course reject a proposal and if a 3rd party agent is interested in the result of the action, it should query the state representation which should give a hint as to what happened (accept/reject).
5/ Sorry I don't understand your question. I am not sure if you have seen the component model I created and I use all the time. Logic is organized in "components" which mount into the SAM implementation. Components contain actions, acceptors and reactors. They could also contain NAPs. Is that what you are talking about? In theory the model is the "next-state-function" that's why the present method triggers all the acceptors.