Not quite - you still need the prepare() (or equivalent) on the atom coordinator, to induce the coordinator to report on the combined vote for the whole atom.

There is then a separate question as to whether the indication that the messages are complete should be in a BTP-defined construct or left to the application. This is hard to give a firm answer on, but I inclinde to a BTP-defined construct. This makes it easy to BTP-ise an application exchange that does not itself have the concept of packaging its requests into groups, without requiring additions to the application messages in an ad-hoc manner.

(arguably an application X + BTP isn't quite the same protocol as X alone and doing so does add messages (the btp allow-vote) to the application messages, but the advantage is that you can do exactly the same thing for Y+BTP, Z+BTP etc). A midway position is to have a BTP-defined "allow-prepare" but also permit voting at any point (used with different applications) - this is truly implicit prepare, but if a service+participant believes it can vote, who are we to say it doesn't understand the application protocol.

atoms, if it needs to know distinctly "will this operation really work", it should ask the atom that includes it. It won't help it to know that the first involved participant is ok, if there is another (directly registered) participant it can't see lower down that will cause the operation to cancel.