I don't see the point of the two arguments: columns_update has to be a subset of columns_select, and the extra columns in the select argument aren't being used?

Please use either array_to_string or string concatenation consistently rather than one and the other.

The function is called update, the main query should be an update.

Is this distinct really needed?

This is inconsistent with the actual function being called

I don't see the point of the two arguments: columns_update has to be a subset of columns_select

I wanted to untangle the complexity in computation of what columns to select and what columns to update.
Debugging those stored procedure is a pain.
Plus, i kept having the wrong result when trying otherwise...

and the extra columns in the select argument aren't being used?

Yes, they are not.
Only the columns_update are to be updated.
The others are effectively dropped.

According to my understanding of the need in T692 (which is the driving need for that api for now) and the 'upsert' documentation.

Sure. Thanks.

Right.

mmm, i guess not. I'll check for this.

I'm not sure i get it.

Do you mean it would be inconsistent to call content_update on inexisting content? I would agree with that.

Or maybe,it's the 'for now' which should be dropped altogether?

I think the inconsistence you meant was that prior the latest development, the initial sql update function used a copy schema to 'update'. Which indeed could have triggered some new rows if fed with new contents.
I was aware of it, thus the comment and the todo below.

Now, the implementation to update is really an update.
So this should no longer be necessary.
I'll remove this and the todo below.