I sympathize with the wish that TADS were open source in general terms: though of course it is always the author’s decision, one consequence of deciding to keep something personal to you is that if you lose the interest in developing it, it doesn’t get developed.
I have to say, OTOH, that the idea of combining Dialog and TADS seems totally bizarre to me: I can’t easily imagine two languages with more different ideas of how a program should be constructed on more or less every level, so I think you’d be constructing a sort of mashup between Latin and Chinese. But … to each their own.
I remain resolutely sceptical about whether lack of suitable languages is a problem for IF. It seems to me that we have a copious supply of languages and tools to suit more or less any preferred style of coding whether for parser-based (Inform6, Inform7, TADS, Dialog, INSTEAD, ADRIFT, ZIL) or choice-based (Twine, Ink, Elm …) and targeting either story+interpreter, web-based, or standalone “app” models (the last of those, for obvious reasons, only with considerable effort in most cases: but that’s inevitable). Most of them are proven (in the “proof of the pudding” sense) to be amply capable of producing work with a high degree of polish in the hands of someone who has put in the time to learn to use them and the time to learn the craft. All of them are equally capable of producing clichéd mediocrity. It’s really not the tools, but the way they are used, that counts.
My hunch is that the biggest problem for TADS is that it backed the wrong horse in the race to web-deployment, and that its second biggest problem is that its API is just too heavyweight, and that its third biggest problem is that it is heavily tied to Windows, and that its final problem is that it now gives the appearance of being more-or-less neglected by its original author. Open sourcing might help with the last of those problems. The rest are solvable, but only by someone who is willing to put in a lot of time.