Full Table

If you want "" to be converted to '', we are going to have to add escaping logic of some kind.

I still need to see what the actual implementation of the two types of strings are.

I'd like to come back to one of my comments from the corresponding discussion thread:

What does assigning initial field values in the constructor body have to do with the field being private?

If anything, it makes a difference whether the right-hand side of the assignment is an immutable value or a mutable one.
In the first case, you could safely assign the value to the prototype's field and even save some memory at runtime (while losing some CPU cycles for prototype-chain-lookup everytime the instance field is accessed).
However, if it is a dynamic expression (new Date().getTime()) or evaluated to a mutable object (like e.g. a new Array []), you have to make sure that every object instance receives its own freshly evaluated value, and so the assignment has to be placed in the constructor. And this has to be done for public fields, too!

For the time being, we should either ignore visibility modifiers completely (at least the compiler has already checked access rights before we even start generating code) or, to avoid name clashes of private members between class inheritance levels at runtime, implement "The Pragmatic Solution" described in my blog post "Simulating ActionScript in JavaScript: Private Members" (please also have a look at the comments).

One more thing, I'd suggest to talk about "fields", not "variables", to clearly distinguish between local variables (which do not need any special treatment by the compiler) and class member variables (= fields). The suggested solution treats private methods similar, so we might even want to talk about "members".

After having had a closer look at the source code of goog.base(), I must say I am not convinced we should use it.
The overloading of calling the super constructor or a specific method as well as the dynamic look-up of the super method introduce unnecessary runtime overhead.

As we know the super class constructor at compile time, calling it can be achieved directly without any utility function. In your example:

org.apache.flex.Button.call(this);

For implementing method super calls, in the Jangaroo Runtime, I reused the mechanism introduced for private members and "back-up" the super class method to a private method before overriding it. This cannot name-clash, as no private method may have the same name as another non-static method of the same class.
Then, the call

  override protected function foo(x:String):int {
    return super.foo(x + "-sub");
  }

is simply converted to something like

  MyClass.prototype.foo$3 = MyClass.prototype.foo; // override => back-up super class method
  MyClass.prototype.foo = function(x) {
    return this.foo$3(x + "-sub"); // invoke method foo of super class
  }

where "$3" corresponds to the inheritance level (again see "Simulating ActionScript in JavaScript: Private Members").
This version is straight-forward and does not introduce any runtime-overhead at all, not even an apply().

Solutions from Jangaroo Runtime:

I think it is not necessary to have all operators and statements in the table, since most of them have exactly the same semantics in ActionScript and JavaScript. To have a more concise table, we should only list those language constructs that actually need rewriting. For example "for each" and all XML-related operators are not present in most JavaScript engines (only Firefox implemented E4X and Mozilla announced that they will probably discontinue supporting it).
Keywords like "protected" need a context so that you can decide how to rewrite them, like you did with the "Fields" group.

So far I have 60 unit tests on my new framework testing binary, unary, member access etc.

I think we should have this table left as is and also make SURE that all ActionScript elements that are possible with the Falcon compiler are listed.

When this project takes off, which it most certainly will, we need all developers that are just writing applications that are being cross compiled to know the conversion or lack there of with every ActionScript element.

What should happen is when we agree on the translated JavaScript it will move to another page table on the wiki of "agreed upon" semantics. This way we have a finite grasp of what we are doing.

As far as I know, the global JavaScript functions Array, Boolean, String, Number, Object work like their ActionScript counterparts: when invoked without new, they still create a new object, effectively converting their argument into the target type. So I think we can just reuse the JavaScript functions.
The only situation where we have to take care is not to generate code for all other type casts, which unfortunately look exactly like a function call. But I hope Falcon can tell the difference.

Concerning a utility function for trace, this Jangaroo runtime part might help; it solves some cross-browser concerns and additionally allows to access different console methods if available without changing the method signature of trace. joo.getQualifiedObject is only used to access global properties in any environment and can simply be replaced by using this in the global scope.

Concerning &&= and ||= (where you put in the question marks): they do not exist in JavaScript and have to be emulated.
The straight-forward emulation for x &&= y is of course x = x && y.
Note however that this way, x is evaluated twice, which might make a difference. E.g. take foo()[bar()] &&= baz(): ActionScript evaluates functions foo and bar once, but the emulation foo()[bar()] = foo()[bar()] && baz() would evaluate them twice. In similar situations, I introduced a helper method, but this is not so easy here, as x appears on the left-hand side of an assignment as well as on the right-hand side. You would have to do trickier things like

var $aux_1, $aux_2;
$aux_1[$aux_2] = ($aux_1 = foo())[$aux_2 = bar()]) && baz();

But it is probably not worth the effort. I think for such rarely used operators, the "almost the same" straight-forward emulation might suffice.

Edit: Thanks Olaf Kummer for the correction that baz was evaluated non-short-circuit in my first version using a helper method! To keep the helper method approach, we would have needed to pass a function to the helper method, making that approach too expensive.