T4675 survives this, because rendering policy controls on the client is very complicated.

In a similar vein, edits to remarkup fields do not use a full control (with bold, italic, etc., buttons) because rendering remarkup controls on the client is somewhat complicated and submitting bulk edits with large amounts of complex text is probably bad most of the time. This is probably not too difficult to overcome (inline comments in Differential already do it to some degree) but seems lower-value.

Not all custom field types are supported, but field types which we've seen requests for are. Additional support is usually straightforward as use cases arise.

The code anticipates working with truly enormous query sets (e.g., millions of objects) but currently always shows the full list on-page, so it will break down at some point. We can scale this up ("This edit affects more than 10K objects so you can not browse or filter individual items from the result set. All items will be affected by the edit.") when someone hits the effective limit. All parts of the pipeline except the "click some checkboxes" UI in the web should scale through this gracefully.