and most users I've talked (even sophisticated ones) are surprised to learn that an impl for fn(&u8) and an impl for fn(&'a u8) are both permitted, etc

(well, that specific example wouldn't be, but you know what I mean)

however I am not sure about that vision, and anyway I have to face the backwards compatibility facts -- i.e., I can't come up with a kind of compelling reason to justify rejecting some of these cases that are currently accepted

fn(&'a fn(&'d)) <: fn(&'?c fn(&'?c))

&'?c fn(&'?c) <: &'a fn(&'d) => '?c: 'a

fn(&'?c) <: fn(&'d)

&'d <: &'?c => 'd: '?c (etc)

So put that all together and you get

'?c: 'a

'?c: 'b

'd: '?c

'e: '?c

and we know from implied bounds that :

'd: 'a,

'e: 'a,

'd: 'b,

'e: 'b.

So yeah that's a case where we can't grow to d, e, or static -- not sure why I thought that couldn't arise, seems like exactly the sort of constraints that you would be looking for. =)

In any case, yes, I think the fallback would be to augment the solver either by introducing union or by making the value of a region equal to a set, but I'm not sure what that latter change would do precisely.