I love where the prototype pitch and implementation have ended up. The beauty of it is that you're generalizing an existing mental model to work in more cases, simplifying rather than complicating the language.
Frankly, even after reviewing the posts above a second time, I'm having trouble seeing how "different generic arguments" would fit into that scheme.
Since implicit member expressions are a convenience (and a very ergonomic one—this is no small feat and by no means would I downplay the importance of its ergonomics), it can certainly be made more convenient for more use cases, which would be made more ergonomic. I get that. I too would want the maximum ergonomics that could be gained from generalizing the existing rules around implicit member expressions.
However, you've enumerated a variety of cases in which allowing "different generic arguments" could break existing code without additional rules or caveats. It seems that taking that additional step would involve more than generalizing an existing mental model, and we'd then be trading some complexity for the additional convenience and ergonomics. This changes the pros and cons of such a plan and makes that additional step not a slam dunk, although it may still in the end be worth it.
The issues you mention don't end when (if) we find a set of rules that work for the compiler to preserve backwards compatibility. I'd like to think it an uncontroversial view that what we allow to be implicit should be (reasonably) easily imputed by a machine but also—crucially—(reasonably) easily discerned by the human reader.
To my view, your example involving integer literals and even your example sInt fall down inexorably on the latter point even if we can devise a set of rules that work for the compiler to preserve backwards compatibility. It's simply not immediately clear to a human what the behavior will be without going through in one's head a set of complex rules like a compiler. Having the option, then, not to state the type in those cases seems a questionable tradeoff; we have to ask if the ergonomics are improved at all if what we allow to be elided isn't actually clear to the human reader upon elision. Recall that clarity at the point of use is a tentpole principle of Swift language design.
Perhaps we will find that these are the most corner of corner cases, and that in general these issues won't arise when we allow "different generic arguments." We do, after all, trust users to use powerful features wisely, and we don't withhold useful features just because in pathologic cases it can be used poorly. But I certainly think that this question requires a more thorough exploration, and we must think seriously if we go down that road about whether some design can allow the majority (or even all) of the non-pathologic cases without incurring the difficulties explored here.
I think all this is to say that the question involving "different generic arguments" is a significant one, greater larger in its scope that the entirety of what's proposed here, and that I agree with @Jumhyn that it merits its own pitch and process.