It's been so long, i don't really remember what i envisioned.
I haven't had a chance to review the patches, but your description of the usecases looks great – my personal preference would be for an empty uf to default to not allowing any explicit fields, but i know i'm in the minority on that opinion, and your "-*" exclusion syntax makes it so easy to do i have absolutely no complaints.
as for field name aliasing / virtual fields (ie:
SOLR-3045) ... as i remember it, the underling "Alias" feature of the DisjunctionMaxQueryParser (i think that's what it's called) should work well for that – assuming the edismax usage of that underlying QueryParser doesn't circumvent it too much.
As far as user syntax goes, i would suggest that the "per-field override" param syntax on the "qf" param would probably make the most sense here instead of using colons (and wouldn't require the special comma syntax you suggest in
SOLR-3045 to specify multiple fields, which would prevent the general change yonik seems to want)
q=elephant title:dumbo who:george
&qf=title^3 firstname lastname^2 description^2 catchall
&uf=title^5 who^2 *
...would cause "elephant" to be searched in all the "qf" fields with the specified boosts; "dumbo" to be searched only against the title field (with a boost of 5 since the user asked for that field explicitly); and "george" will get a DisjunctionMaxQuery with a boost of 2, containing two clauses: firstname (default boost of 1) and lastname (boost of 10).
Basically: when parsing the "uf" look for a "f.$
.qf" param, and if it exists parse it and add the appropriate Alias. (fingers crossed it will be that easy: if it isn't, it's probably a feature!)