Thanks @neonstalwart comments have been helpful.

Yes, I did wonder about just inlining it yesterday, when thinking about this.

I originally went down the route of a separate file as that seemed like the standard formula (ie. with Rhino and Node).  Anyway, it does look like it could all be put into dojo.js without making it much longer.  It seems unnecessary to complicate things too much.  I also find the creation of a global function annoying and think it'd better to get rid of this.

Yes I filed a suggestion about staticHasFeatures (see: https://bugs.dojotoolkit.org/ticket/17193) a while ago.  It is not possible to get a good build that will run in both workers and the browser window without tweaking these.

Okay, I take the point on calculating the path.  It will require some more work to get this right.  Although, the nature of webworkers means that setup will be more complicated for the end user.  It's a shame we cannot use dojo's internal path calculations here but these seem to be dependent on DOM.  I will try to thrash out a fuller implementation of the path calculation.

What do you reckon on this front?  I do not want to pollute the dojo.js with lines and lines of path calculations but I also do not want to make too many assumptions about how it will be used.  Is it reasonable to have a more limited options pool when configuring dojo in workers? You are already limited by not being able to access Dom related functions.  It could be that people are running a very complex config in the browser window but it doesn't necessarily translate that they will use an equal config in their workers.

I'll take advice here and then try to pad-out path calculations.