Let us analyse your code a bit to identify the problem. First let's replace bt[3] by 'myfunc' and bt[4] by 'params'.
That would give us the following code:

local fCall = assert(loadstring(myfunc.."("..params..")"))
a, b = fCall()
self:addHistoryEntry("Returned: "..tostring(a).." and "..tostring(b))

Now, what does loadstring do? Create a chunk from the given data. Basically, create a function with the contents that you pass to loadstring. So if we evaluate what actually happens, we get something like this:
function fCall()
   myfunc(params)
end

As you can see, the function will never return anything because it doesn't contain a return statement. So there is your problem

Now, about the code itself, do not use loadstring for this. It will significantly slow down your script. Rather do something like this:
local params = {}
for i = 4, #bt do
   table.insert(params, bt[i])
end
local myfunc = _G[bt[3]] -- if it's a global function that is
a, b = myfunc(unpack(params))
self:addHistoryEntry("Returned: "..tostring(a).." and "..tostring(b))

Now, this is code for the situation that you have now. If possible, just pass the function as a reference, not as a string. Then put all the parameters in a table so that you don't need to copy them in a new one. Something like this:
{data, data, functionreference, {param1, param2}}
Then you could do a, b = bt[3](unpack(bt[4]))

With this update, I corrected the call system on the console.

Here is a partial example program that I was working on for physics, but unfortunately never finished before the test 
It displays several important things that can be done with WZ such as encapsulating forms with all of their objects into classes and event binding.
It also shows my bad graphics drawing abilities 

I got my license and will be resuming development. During my break I have been working on improving my C skills and am really considering porting everything to C. By keeping all of the WZ definitions abstract this project would be very portable and would allow way more flexibility. I guess we will see what happens when the time comes. Until then I need to finish up my documentation before classes resume so maybe expect something by the end of next week? I am a slave to my schedule so I will see how it goes.

can't wait for the PRIZM version, I have a project I would like to do but I need WZGUILIB.

I think. LuaZM should be fine enough, but I guess Flyingfisch and Kerm would need to confirm.

So Last night I did a little bit of messing around with the button drawing code and came up with this. Which of the three do you like better?