Priority of this is raised if using InnoDB, as additional write queries has non-trivial overhead in terms of establishing logs and updating the ACID log.

These functions in v9 are worth looking at (initially implementing this as a sponsorship for a customer)...

get_num_users_site
render_field_value url.php
put_into_cache
do_comcode_attachments
_do_tags_comcode
ocf_ping_topic_read
edit_ping_script
find_theme_image
check_url_exists
_update_read_status
member_tracking_update
set_tutorial_link

Note that most DBs that implement a merge feature do not do it as simply as MySQL. For us to support those we'd either need to pass in the key fields with each REPLACE query, or we'd need to read them from the DB - complexity that I think is not worth it.

Therefore I think a better implementation is to make a new query_insert_or_replace database method, and if this returns false, do the current method of delete then insert with error ignoring. Messy, but we're only targeting changes to a few critical highly trafficked cases here.

Actually, I've implemented query_insert_or_replace as a similar function signature to query_update and query_delete. i.e. separated the key params+values from the rest of the params+values. This works nicely, as no extra parameters are needed for the DB layer to fallback to the old query_delete/query_insert way of doing things.

This is now implemented for MySQL, and can be implemented by any DB driver that wants to. I'm leaving this open for if we want to implement on other DB backends.
The syntax is lot cleaner on MySQL.