Thanks for your reply, I'll try to answer every question.

1) I found creation of .xpi quite simple, and that would be the easiest part of this project. As far as I know, we shouldn't have to do here more than a standard structure like for every xpi, which I've already learned.

2) In the manifest file of our xpi we need to register a component with an interface to the Mozilla's XPCOM. The C part will be the hardest part of this project, as far as I can tell from few days research. 
2a) I feel very good in C, in C++ little less, but still I think I can handle this job. Mozilla's tutorials for XPCOM components are written quite good, the only thing is they need couple of changes to handle new interface. Gecko 2.0 brings many of it.
2b) As we register our component, we'll be able to send <script> part to it, even from a JS call, so if tclsh could be connected to this component too, we could interpret this script.

3) XPCOM provides several classes and interfaces to interact with DOM. Just look at  http://mxr.mozilla.org/mozilla-central/source/content/html/document/src/nsHTMLDocument.h and it's includes. I haven't yet tested how this could work, but for now I see no reason why it shouldn't. To handle DOM access from Tcl we should provide separate library based on XPCOM, or that's the way I understand it for now.

I've tried to build the existing TclXPCOM library, but without success. This is because some parts of XPCOM interface wen't from public to private and inheritance of some classes isn't valid for this reason. But TclXPCOM have been made over 8 years ago and no updates from then were seen, so it's only natural that it isn't working out of hand.

Some information could be taken from pyxpcom or javaxpcom as they seem to do similar things with python and java.

I'll do some more research to look closer to communication through XPCOM interfaces.

Thanks,
Adam