I don't understand why are you want to use all three flags (ihr, bounce, bounced) if you need only first. less changes in schemes.

also not all messages in the past has flag ihr_disabled = true

select ihr_disabled, msg_type, count(1)  from blockchain.messages group by ihr_disabled, msg_type
+------------+---------+---------+
|ihr_disabled|msg_type |count    |
+------------+---------+---------+
|false       |ExtInMsg |53448826 |
|false       |ExtOutMsg|1923844  |
|false       |IntMsg   |3417621  |
|true        |IntMsg   |248430531|
+------------+---------+---------+

so we will need to parse old messages with one scheme and new with another based on additional context information

Another opportunity for new type of special messages is InternalExternal type:
that is message sent by onchain and delivered to the destination via hypercube router, however processed by TVM as external message:

1. function selector set to -1
2. balance bm of inbound message equal to real message balance
3. Initial gas credit gc = 0, the initial current gas limit gl calculated the same way as with internal message

This will allow
a) gasless support even from old wallets
b) smart-contract unstucking in the case when it expects external message but for some reason doesn't fit to gas credit anymore

int_msg_info_external$01110000 _:CommonInternalMsgInfo = CommonMsgInfo;

can be used for this

#141

An alternative is to allocate a fundamental smart contract, which would respond to a message address with state of that address at the beginning of the relevant masterchain block. Then, the requester might do anything using RUNVM or like.

Proof that this produces expected results with TON transaction ordering is left to the reader.