Rendering arbitrary SVG content in SVG font glyphs

It seems to me that no major Web browser supports rendering arbitrary SVG
content for an SVG Font glyph. For example, this testcase displays nothing
in Webkit and Opera:

<svg xmlns="http://www.w3.org/2000/svg" >
  <font id="Font">
    <font-face font-family="Test" units-per-em="2048"/>
    <glyph unicode="@" horiz-adv-x="1000">
      <rect x="0" y="0" width="1000" height="1000" fill="cyan"/>
    </glyph>
  </font>
  <text x="0" y="100" style="font-family:Test; font-size:80px;">@@@</text>
</svg>

A completely general implementation of this feature in a Web browser would
be very difficult. For example, the SVG content for a glyph could be
  <foreignObject x="0" y="0" width="1000" height="1000"><html:iframe src="
http://mozilla.com"/></foreignObject>
The SVG 1.1 spec requires you to create anonymous cloned iframe objects for
each glyph, which have to be associated with the text in some way. Because
these objects are stateful, the spec would need to define exactly when this
binding happens. For example, if I append a character to the text node, are
all the anonymous nodes recreated or is one just appended? The problem is
especially acute if you want to support this for non-SVG text.

The requirement that CSS inherit from the text, to the <font> element, to
the <glyph>, may also be hard to implement. As noted in the spec it can also
produce very unintuitive results because SVG styles like stroke-width will
be interpreted in the glyph's coordinate space, which the text author may
know nothing about.

Chris Lilley pointed out in a Mozilla newsgroup that one-off decorative
glyphs for a particular page are a good use case for this: it's just like
producing artwork except your text is searchable, accessible, etc. Is that
the only use-case? Could we satisfy that use-case in some other way? One
possibility that seems attractive to me is to redefine the way glyph content
is rendered so that it's treated like a pattern instead of a <use>. Not
having to manage anonymous content for text would make this far easier to
implement, for Gecko anyway, and it would also perform much better. It would
mean losing the ability to inherit style from the text itself. However, as
far as I can tell, the main need is to be able to use the text color in the
glyph content. We could support that in fill and stroke by defining a new
paint server "textColor" which magically extracts the color from the text
the glyph belongs to.

Rob
-- 
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed. We all, like sheep, have gone astray, each of us has turned to his
own way; and the LORD has laid on him the iniquity of us all." [Isaiah
53:5-6]