Major Description
When "In-Place" DocValue updates were added to Solr, the choice was made to re-use the existing "Atomic Update" syntax, and use the DocValue updating code if possible based on the index & schema, otherwise fall back to the existing Atomic Update logic (to re-index the entire document). In essence, "In-Place Atomic Updates" are treated as a (possible) optimization to "regular" Atomic Updates
This works fine, but it leaves open the possibility of a "gotcha" situation where users may (reasonably) assume that an update can be done "In-Place" but some aspect of the schema prevents it, and the performance of the updates doesn't meet expectations (notably in the case of things like deeply nested documents, where the re-indexing cost is multiplicative based on the total size of the document tree)
I think it would be a good idea to support an optional request param users can specify with the semantics that say "If this update is an Atomic Update, fail to execute it unless it can be done In-Place"