Any successfully sent message is always delivered, this is guaranteed by message queues in shardchains.
If the receiving contract failed processing of message (computation phase exit_code not 0 and not 1), and message contains enough value and was sent with bounceable flag, then the bounce message is guaranteed to be sent.

I see. And what about timeouts on messages? Always delivered within a timeframe? Or I guess it probably determined by the existing network load and generally quite fast.

Also what is proof that a message has been sent successfully? And is that proof always available to the sending contract?

Messages are delivered in order of their creation, usually quite fast.
You may be interested in chapter 2. https://ton.org/docs/tblkch.pdf

If the message was sent with mode & 2 == 0, then either the full transaction fails or this outgoing message is sent.
Otherwise, there is no way to check whether message was sent (or counting balance, but that's error prone...)

Ok and record of message being sent and its mode is stored locally in the sending contracts own data? or this is just an implementation option for the sender?

No, nothing is stored in contract data when sending message. Your contract may save them, but the message data has no use.
By the way, this allows to keep storage fees small, or transactions list could eat up the contract balance.

This can also be useful:
https://ton.org/docs/develop/smart-contracts/guidelines/message-delivery-guarantees

Oh, this article wasn't in place when I visited documentation last time)

I will definitely take a look. I know we want to keep the memory footprint of the contracts light. Perhaps just some meta-data can be stored about the last message sent and overwritten when transaction completes ...

"messages that were sent from one account and transactions which happened on one account are strictly ordered as well. Thanks to this, for every account we always know the order of transactions, received messages and sent messages." I know that TONAPI has a trace facility but from within the account contract how would this information be accessed?

The contract cannot access blockchain state. Not even its own code as cell.