• AutoHotkey — The lead author is wedded to the idea that the syntax should be kept "simple" (even though the simplest grammars are those that have been designed properly up-front, rather than piling kludge upon kludge).
• AutoIt — Went from being open-source to closed-source due to a misunderstanding about what open-source is about.

Possibiities include:

• Integrate Lua into the AutoHotkey code (possibly allowing for some way to specify whether it's Lua code or AHK code at the top of the script). Pros: lightweight, efficient, and mature. Cons: It's not clear to what extent architectural issues might this more difficult.
• Re-write the functionality in a .NET library (eg. implemented in C#, or ...). Pros: Would make the functionality available to a WIDE variety of languages, including ones that allow runtime compilation and/or eval() (ie. potentially a very large userbase). Also, bytecode compiled languages are fast and small. Also, C# has much better support for win32 stuff, from DllCall() to Framework APIs to GUI builder to ....

Lua

• Is there an easy way to call Line::Perform() on the fly? That'd be nearly perfect, since we really do want to use Lua for the control-structures, and only have AutoHotkey do the magic stuff that it's good at.
• How does multithreading + Lua + AHK's stuff work?
• Is there any chance Chris would consider allowing it to be maintained within the same codebase? (if one went to a lot of effort to minimise changes, etc etc)

.NET Framework (C#, Managed JScript, ...)

• AutoHotkey's multithreading is nearly invisible (as long as you want to stay within the bounds of its box). Is there any way to get C#'s multithreading close to that?
• How much effort would it be to re-implement everything within .NET? Answer... a lot?