it is by design. In fact hunt list is something that NEEDS to be re-written entirely. Currently its using chan_local nesting a dial within a dial. This has resulted in a myriad of dialplan problems that progress as 1.4 is 'fixed' from other runaway bugs. You will notice that macro-tl-userexten has a condition set if its a ring group to call a different handler. That handler is there because features like screening and forwards were literally hijacking the ring group denying other members access.

The proper way to conduct a ring group is

Dial(SIP/ext1&SIP/ext2&SIP/ext3,timout,i) (i to ignore forwards so it prevents hijacking)

currently its Dial(Local/ext1@local-extensions-tenant&Local/ext2@local-extensions-tenant,timeout)

which runs through the dialplan running userexten macro's that invoke yet another Dial statement, upon timeout or failure, LOTS of bad things happen

bugs related to hunt list and chan_local currently causing problems:

1) timeout of nested Dial replaces ARG1 ARG2 etc with the original ARG1 ARG2 etc of the originally invoked macro.

2) if all the channels are not available or some other DIALSTATUS occurs the call hangs up, it does not proceed in the huntlist dialplan. This can be illustrated by creating a hunt list that calls 3 phones but those 3 phones arent registered, and then goes to the goto-voicemail script. Call the hunt list, watch a hangup occur instead of going to a hunt list

The hunt list code needs to call the technology channel directly and then run additional events, not recurse macro's:

exten => s,1,Dial(SIP/100&IAX2/102&SIP/103,20,i)

exten => s,n,Macro(goto-voicemail,mailbox,u)

then if you wanted to have some 'blacklist' for the huntlist it would be done before the dial

exten => s,1,GotoIF(dbexists(database/key/value)?skip)

exten => s,n,Dial(SIP/100&IAX2/102&SIP/103,20,i)

exten => s,n,Dial(SIP/105,20,i)

exten => s,n(skip),Macro(goto-voicemail,mailbox,u)