I don't think that would work the way extensions are currently handled.
All <references> tags would be handled after all <refs>, and they don't
have any positional information.

bugs wrote:

Would it be possible to have a <clearrefs> tag, which purges the current cache?
In other words so that:

some<ref>foo</ref> text
<references />
<clearrefs />
intermediate text

more<ref>bar</ref> text
<references />

would produce:
some[1] text

1. foo

intermediate text

more[1] text

1. bar

Currently, the following is produced:
some[1] text

1. foo
2. bar

intermediate text

more[1] text

1. foo
2. bar

If transclusion is used, then the "2. bar" does not appear in the first
references section.
Tests:
Without transclusion: http://en.wikipedia.org/wiki/User:Stevage/bug5810
With transclusion: http://en.wikipedia.org/wiki/User:Stevage/bug5810a

No, it would not.

We have <ref name="x"> to create multiple referencesto the same note.

But why not having <ref type="x"> for creating several independant lists in articles? Then to generate the
list of references of the same type we would have <references type="x" /> and this would select only the
references of that type (the absence of the type attribute in references tag would list all untyped refs
only).

We could optionally use <references type="*" /> to generate all references, merged into a single list, and
<references type="x,y" /> to select only the enumerated types, or <references type="x,y,-z" /> to exclude
refs with type z (the selection of refs to generate is made by the union of positive type selectors, minus
the union of negative selectors.)

The text in a <ref>element may also embed other text in a <ref>, allowing notes to refer to each other. (But
first, the parser should be corrected so that it collects all footnotes in the article, including those that
are wiki-encoded after the <references /> wikitag.

There would still be only one numbering, whatever the type specified in <ref type="...">...</ref> elements.

v111p wrote:

I suggest instead of "type", "group" is used, and every group is printed with a <references
group="name_of_the_group"/>. <references/> (no group specified) prints the rest of the references.
What Philippe suggests is too complicated. Why would you want to print 2, 3 or all reference groups
into one list??

The parser in 1.7 now processes tags in order, making it
possible in theory to do a clear at each <references/>.

I note that your sample page no longer uses any
transclusions, making it impossible to test the current
situation.

bugs wrote:

yeah, someone pointed out rightly that I was transcluding all the categories as
well and killed it. do the test cases in my comment #2 help?

ayg wrote:

Bug 6271 would allow one implementation of this.

webboy wrote:

(In reply to comment #6)

The parser in 1.7 now processes tags in order, making it
possible in theory to do a clear at each <references/>.

Done in r32290 by sanbeg.