Loop in UML activity diagram using a region

I am modeling a loop in an UML activity diagram. It works well with simple condition nodes (diagram 1), but I am looking for a more expressive way to emphasise the loop semantic. So I came to "regions" or "interruptible regions" which are shown here and there, but I couldn't find many really satisfying examples.

My example is a function which processes messages of a given list. The loop aborts as soon as the first valid message is found, then the message is processed and the function returns true. Otherwise, it returns false (please no comments on sense or nonsense, it's only for the sake of a sample).

Diagram 1: uses a good old activity diagram conditional node. It is easier to follow the control flow along the arrows, admittedly, but there is no "The LOOP", there is just an "if".

Diagram 2:

is the (positive) exit condition correct, using an interrupting edge? True, it could be part of the [test] section of the loop along with the iterator.
BTW: how is the iterating character of a for-loop best expressed in UML?
Is the activity final node inside the loop body correct (i.e. when the conditional "message valid?" yields "no")? It somehow feels wrong to use a final node here, but how else can I express the control flow of one loop?

The functionality of both diagrams should be equivalent:

Edit: Another diagram which implements the suggestions from Steph:

Initial and final node inside the loop body
"further processing" is now inside the loop body. Well... OK here but there might be other loops where I would rather have it outside. Then I might change the design anyway...
The "next message" can also be seen as the iterator object itself instead of the action "(provide the) next message" from the original diagram.
The two object flow arrows might be a bit overkill, but I think they are correct.

In UML, the activity final node represents a completion, so it is correct in a loop region as you use it, it is the normal completion of the content of your loop (which in turns leads to the next iteration). As a side note, I advise you to also use an initial node for the beginning of your loop.

And there is also the flow final node, that represents an exit, instead of a completion. Thus, you can use it to represent the "break" statement, instead of the interrupting edge you use. In this case you have to integrate the "further message processing node", in the "yes" branch, just before this flow final node.

The interrupting edge is rather for interruptions coming from outside the current processing. The region is interruptible, and some events (usually noted with receive nodes) may completely interrupt it no matter the progress of the region content. Here it is not the case.

Concerning the iterating character, there is nothing very visual, unfortunately. I tend to use an object node on top of the region, just beside the initial node.