i wouldn’t want to write or read some Dictionary, because it is discarding some relevant information about the two type parameters, namely that the Key is Hashable. so i would prefer to write it:
func ƒ(_:[some Hashable: some Any])
moreover, i rarely want to abstract all the way down to [some Hashable: some Any] at all, more likely i would write APIs that look like
func ƒ(_:[some MyKeyProtocol: some MyValueProtocol])
Multiple primary associated types (along with unlimited non-primary ones) are already supported with a single some, so the "any number" part wouldn't be new.
import protocol Combine.Publisher
func ƒ(_: some Publisher) { } // is shorthand for
func ƒ(_: some Publisher<some Any, some Any>) { }
What would add ambiguity would be a some coming before something that is not a protocol or superclass. Maybe that's not good. (Although PascalCase is the convention for so many different types of things, I'm inclined to lean towards, "just option-click it if you need to learn about it" the way we've always had to.) Can any be done differently though? The some stuff here is sugar, but the any is a missing feature.
I'm not sure what you mean by "discarded"—you can't subvert the requirement.
That works already though—go write it! 
I hadn't thought before today about how asymmetric it is that only the last line here does not compile.
protocol Protocol<T> { associatedtype T }
final class Class<T> { }
func ƒ(_: some Protocol<some Any>) { }
func ƒ(_: some Class<some Any>) { }
func ƒ(_: some Protocol) { }
func ƒ(_: some Class) { }