It does seem to be a genuine blind transfer:
1151. [2023-03-14 17:17:35] VERBOSE[119910][C-00000017] app_macro.c: Channel 'Local/[email protected];2' jumping out of macro 'dial-one'
1152. [2023-03-14 17:17:35] VERBOSE[119910][C-00000017] app_macro.c: Channel 'Local/[email protected];2' jumping out of macro 'exten-vm'
1153. [2023-03-14 17:17:35] VERBOSE[119910][C-00000017] pbx.c: Executing [[email protected]:1] GotoIf("Local/[email protected];2", "0?ext-local,*102,1") in new stack
and it isn’t requesting music on hold when dialling PJSIP/102
1339. [2023-03-14 17:17:35] VERBOSE[119910][C-00000017] pbx.c: Executing [[email protected]:56] Dial("Local/[email protected];2", "PJSIP/102/sip:[email protected]:1026;ob,,HhtrM(auto-blkvm)Ib(func-apply-sipheaders^s^1)") in new stack
The main obvious difference is that it is using context from-internal-xfer, not from-internal, or from-queue, which suggests this might be a FreePBX issue rather than an Asterisk one (I’d only expect Asterisk to get into trouble on attended transfers).
There is no m(0… anywhere in the trace, so I assume that from-queue doesn’t honour this either.
Especially without an example of this working, I think it is going to take me too long to trawl the code to see why it is not getting set on this path. It is always possible that this is intended behaviour, for some reason. It is possible that there was a policy decision that dial options should not change during a call, but should reflect the initial DID/dialled number used.
It does, however, look to me as though the only place this would get set in the current code might be here:
128. [2023-03-14 17:16:10] VERBOSE[119714][C-00000017] pbx.c: Executing [[email protected]:5] ExecIf("PJSIP/10000-0000003f", "1?Set(_DIAL_OPTIONS=HhTtrM(auto-blkvm))") in new stack
which suggests that setting it for the queue might affect the transfer, always assuming that setting it for the queue is compatible with what you want to achieve.