I allow myself to add Julian Eisel here (@julianeisel) since I think there is here a UX/UI point.

So no, I didn't enabled nor build proxies in clip editor before changing the Proxy Render Size value. I followed your link and now I am able to make the proxy of the background images for the clip work. Kind of.
So I guess there is no "functional" bug here. But there are to me some UI and UX issues, plus some missing information in the documentation.

I explain myself:
I am not used to use the proxy system. So when I changed the clip proxy value in the Background Images of the camera and I faced this double strange behavior that either the resolution of my clip in teh viewport was not changing or in some cases it became pink I first thought at a wrong manipulation from my behalf.
I then went to the camera documentation: https://docs.blender.org/manual/en/latest/render/cameras.html?highlight=background%20images%20camera It was not mentionned anything about the clip proxy settings. At least a link to the Clip documentation page would have help to put me on the right path.
I then thought about a possible bug, but I wanted to be sure I did the right manipulation, so I went to the blender chat, in support, and asked for a confirmation: https://blender.chat/channel/support?msg=FqdoNWiTowFodDFNv
NiCapp answered me and advised me to report it as a bug.

So my point is that the use of proxies is apparently unclear not only for "newbies" but also for experienced users.

To me, if the feature is working in itself is cannot be considered as "usable" in its current state.

I then suggest the following improvements ((I'm UX/UI designer btw):

• The user should be led to the activation of the proxy settings of the clip thanks to the interface: a popup message could appear when the proxy settings of the camera background clip are changed saying that the clip currently has no proxy associated and should indicate where to change it (namely at the other side of the application, in a workspace I just discovered tonight dedicated to clips - so far I thought it was for image tracking)).
• The 2 strange behaviors of image quality not changing and pink images should only appear in case of an error: At the moment they are clearly misleading - or leading to think there is a bug. Either nothing changes and there is a popup message mentioned above or things are changed automatically (ie the proxies are generated transparently) and the images in the viewport then get the expected resolution. Pink color should be let for real error, such as proxy not generated for some reason that is not due to a missing user manipulation (an error in the cache path for example, or low memory).
• As I experienced just now it also appears - as far as I see - that the user must generate a proxy for each resolution - manually - in order to use it. Why not generating only the one the user needs, this directly from the place where the clip is used and the proxy settings are accessible (in this case the camera background images panel)? That would save trickky manipulations for the user, save him time, save coders time (I will have to implement all thoses manipulations in my add-on to make the camera background proxies work? That is certainly a huge work and I already miss time to support my production) and it will be far more intuitive and predictable for all users, whatever their level of experience.
• There is also a UI point that could be made a bit clearer: in the Proxy Render Size dropdown list there is at the same time 100% and Full Render. Well, if 25%...100% are refering to the proxy resolution then 100% is the same resolution than full, by definition. I guess Full then refers to "original footage, without additional compression". Maybe the item "100%" could be renamed to "100% - Compressed", if that's what is happening.

I got a better understanding of the use of the proxies in general in the application now thanks to all this and my point of view is that is it currently a pretty laborious and unclear workflow. There is very likely some room for improvement here.
Thank you very much for your attention to this.

Updated the manual to have some more info on this, rBM6834: https://docs.blender.org/manual/en/dev/render/cameras.html#background-images.

One thing we could do in Blender is grey the proxy settings out if there is no proxy data and adding a disabled-hint in the tooltip (which we want to do more often). However, looking into this, it's actually not so easy (tm)... I don't see a decent way to mark the item as non-editable in RNA, which is the way we have to do it for the disabled hint. Maybe it's time to add disabled-hint support for UILayout.enabled (we should have that anyway).
Another issue is that we can't tell if the proxy is available without testing for the available proxy sizes on disk - which we'd have to do on every redraw for the check. That's too expensive to be an option.

What I think we should do is, store in the clip if proxies were built for a certain size. If the files can not be found on disk, we can show the pink image, possibly with some other hint.

Of course adding a button to build the proxies in-place could also work, but there are a number of settings we should expose for that. How would that look like?

Anyway, these are my two cents. I don't really have further time to work on this myself.

These are very good and valuable possible answers :)

Regarding the pink image feedback there may also have something to do here:

• Currently when something (anything in fact) is going wrong with the images to display then the image (or clip, or texture...) is replaced by a pink filled rectangle. This has the good side to tell the user something went wrong, but the downside that there is absolutely no clue on what. Plus the fact that it may modify the original media behavior: for example when we use a clip background for the cameras and the proxy is not generated then we get:
  • a pink rectangle that is lasting forever (ie longuer that the original media), which is quite disturbing. The expected behavior would probably be that the pink gets transparent after the end of the media (as the media itself) (and in case of course that the media end is not on "hold" state)
  • in the specific case of the camera images background the pink rectangle is fully opaque. It then completely occludes the scene and that's a real issue to manipulate the scene. The expected behavior here is clearly that it should respect the Alpha value set for the camera background.

I think we are at a point where there something really cool to do with this pink rectangle. In the 2D/3D prod application I was in charge of we changed this same filled color we had to more contextual and self-explainatory images. Most of the cases were covered and the user was able to spot the origin of the issue at a single glace without having us to develop specific complex stuff for the UI. Here there are (the Media Cache was used for missing proxy, and the green one was used for textures, allowing us to quickly open a 3D scene while the texture proxies were assynchroneouly being generated):

So let's imagine how helpful these contextual error images would be in Blender, for all users in any editor, and for a development cost that is really reduced !