The short-term/quick solution is porting Gijs' commit and extend the Canvas projection handling code accordingly, but in the mid-term, it would be better to provide a mechanism for registering custom projection handling code, because the number of Canvas use-cases where a hard-coded scheme would quickly show its limits, is still growing, e.g. referring to vertical projection displays (think omega95's VSD) or Thorsten's orbital map.
Thus, we really need to be sure that we provide APIs that "scale", or people will sooner or later end up implementing slow Nasal/Canvas based code, due to the lack of generic, and fast, projection handling support (to be fair, we once contemplated adding a generic projection handling library like
proj4)