Thanks for the heads up. I have no concerns about evolving the API, given its current state of implementation.
"nobody could articulate why the API was ID-based rather than element-based,"
If I recall correctly, there was protracted discussion about having an ID-based API *and* and alternative element-based API. One of the arguments for an ID-based interface was to ensure that developers could create accessible canvas elements without having to create a 'costly' DOM element for each object in the canvas that needed to be made accessible. (Consider the case where the canvas is used to draw a scatter plot with a huge number of points, or is used to draw a star map with a huge number of stars.) Personally, I feel a single element-only approach is simpler.
"why it had to be 2d-context specific"
I think this was just an oversight.
"why the region ID had to be exposed on event classes."
I think this was the consensus solution for the case where no element was used (the ID-based path). There are no doubt better approaches here - for one, .region is a very generic name.