@WarrenBelz Sadly no, the code snippet you pointed out was pseudo code where i simply forgot to properly type out the references.
However, from the response code you provided, if the Patch() did a LookUp() like: Patch(List, LookUp(List, ID = _lookup.ParentID), { Column1: Coalesce(_row.Column1, _lookup.Column1) })
The LookUp() inside the patch would now be non-delegable, because even if _lookup.ParentID is a number column, it will fail the type check with the same error: "The LookUp function cannot be delegated if a field value appears in the second argument".
I'm very well aware that With() is just intended to be for block scoping, it's also the entire reason i work with it so often to reduce variable / collection overhead in my apps where it isn't necessary, my point is that how these variables resolve field values has recently changed behaviour across multiple tenants and environments (Also verified by coworkers.).
As i cannot post my code publicly without obfuscating it and my attempts to do so have been poor that i've been misunderstood, i'll try to explain a common scenario and how it differs instead:
Applying a With() to block scope a filtered down list where i can then do a ForAll() over the filtered list.
Inside this I check for a condition and if the condition is met i run another With() block to do a lookup / filter, because i might need to copy several values of a related record or do some math operations. From this point i used to be able to write these values back into the original record by referencing my block scoped LookUp() inside the With()-function by using dot notation to access different columns. This has always been delegable previously (As long as your lookup/filter follows delegation limitations.), however this has now changed.
Trying to write a single line of text value from the LookUp() inside the condition of the ForAll back to the data source now throws a delegation warning, because accessing the columns by dot notation throws warnings that a column of the type single line of text does not expect a field value and may be non-delegable.
This implies that the LookUp() inside the With() creates a direct reference to the original data source, making the type of the columns "field values", rather than an object with type defined key-value pairs mirroring the original (I'm aware it always hid additional metadata like the etags under the hood.).
IF you define the LookUp() using dot notation directly in the With()-function however, the reference resolves to it's expected type indicating that there's some mismatch in how the field values are resolved.
This can in some cases be worked around by adding a nested With(), similarly to the following pseudo code: With({ _loookup: LookUp() }, With({ _col1: _lookup.col1, _col2: _lookup.col2 }, <Data operations using _col1 and _col2 goes here> ))
However this would not properly resolve the type definitions and cause delegation warnings: With({ _loookup: LookUp() }, <Data operations using _lookup.col1 and _lookup.col2 goes here> )
This was not an issue 2 weeks ago, as the dot notation resolved the type automatically (Manually converting using Text(), Value() or GUID() does not work either.).
I have previously verified the delegation as fully functional both by using the live monitoring tool and by having it filter data sources containing far more records than the row limits of non-delegable filters.
This suggests that something in how the data is stored and referenced inside powerapps has changed, probably due to optimizing the advanced analysis engine, but some edge case in the With()-function has caused it to no longer resolve the proper type definitions in certain scenarios.
