cc @xedin

My example (https://stackoverflow.com/questions/59653363/more-about-the-weird-behavior-of-referencewritablekeypath-with-an-optional-prope) is a little different but I think it's the same phenomenon?

`self.iv` is a typical IBOutlet property declared as an IUO:

    let im = UIImage()
    let kp = \UIImageView.image
    self.iv[keyPath:kp] = im // error

But now watch this. Instead of an outlet, I'll just make an image view:

    let im = UIImage()
    let kp = \UIImageView.image
    let iv = UIImageView()
    iv[keyPath:kp] = im

That compiles! Why? What semantic / syntactic difference is there between a UIImageView property and a UIImageView local? Is it that the property is an implicitly unwrapped Optional?
To test that idea, let's "propagate" the unwrapping of self.iv explicitly through a local:

    let im = UIImage()
    let kp = \UIImageView.image
    let iv = self.iv!
    iv[keyPath:kp] = im

That compiles too! But we must use a separate local; merely unwrapping self.iv directly is not sufficient:

    let im = UIImage()
    let kp = \UIImageView.image
    self.iv![keyPath:kp] = im // error

Personally I think they should all compile, on the grounds that (1) an implicitly unwrapped optional should behave like the wrapped type, and (2) one should be able to assign the wrapped type to an optional. An image view's `image` is an Optional UIImage so one should be able to assign a UIImage to it (including a UIImage!).

cc @hamishknight