just to clarify the situation. I just rechecked the code.
context.source is present and holds the issuing elem reference
_mfInternal is as the name says a data holder which is bound to change depending on the implementation version, unfortunately the spec does not say anything about this case and I needed to have this data for a certain bugfix condition and some additional functionality. But just for the short explanation of what can be found there
var mfInternal = context._mfInternal;
mfInternal["_mfSourceFormId"] = form.id;
mfInternal["_mfSourceControlId"] = elementId;
mfInternal["_mfTransportType"] = transportType;
mfSourceFormId the issuing form id
mfSourceControlId the source control id
mfTransportType the transport type, we allow several types of transport types, this is some preparation work for jsf 2.2 and also enables us to allow multipart iframe based "ajax" submits.
This is more meta info than context.source can give you, because the spec html clearly states that context.source must have only the source element which then at the request time will be replaced with the dom node for the element. Now our problem was that once you have the node you can run into a situation that the node on the protocol side can be replaced and suddenly you might run into a situation where you cannot reference the nodes parent form anymore, hence i stored this data here.
mfInternal["_mfSourceControlId"] = elementId; is somewhat redundant but it is wise to drag the parent form id into the context as well (we had a bug raised on detached forms by one of our users)
But as I said this is internal data and is bound to change in the impl, or will be dropped as soon as the official spec takes care of the form id issue.