First of all. Disclaimer: I’m not a coder, so from where I’m sitting (on the fence), great work! 
I tried out the second, merge_frontmatter_function.
My testing is not comprehensive.
I really like the option of being able to select functions. It’s like plugin settings.
1
If I may make a suggestion (not sure how easy it would be to implement)…
From what I understand about the workings and YAML treatment of Obsidian (largely through the workings/settings of the fantastic community plugin Linter and the chats I’ve had with the developer/maintainer of the plugin – I sent him on more wild goose chases than he had bargained for), some values are Boolean, some are text strings, some are multi-line, some are not…etc. The Properties UI panel sometimes used to alert me to invalid properties such as topic and parent_topic fields being not properly addressed – not anymore, it seems.
So my question is, is it possible to merge the add and update functions – based on whether the keys in question are sporting single-line status fields?
I have a feeling that Obsidian still has some quirks handling these cases and you need to wait with the final solution but we should keep our options open – otherwise the user must be aware that the status properties will NOT be updated unless he adds update. As I managed it using some conditionals in my use case:
const fileContent = await app.vault.read(currentFile);
const formattedDateTime = await tp.date.now("YYYY-MM-DDTHH:mm");
const properties = [];
// Check if dg_upload or status exists in frontmatter
if (!fileContent.includes('dg-updated:')) {
// If "dg-updated" doesn't exist, add it
properties.push(
{ key: 'dg-created', value: formattedDateTime },
{ key: 'dg-updated', value: formattedDateTime },
{ key: 'dg_upload', treatment: 'update', value: 'VNC done' }
);
} else {
// If "dg-updated" already exists, just update the timestamp
properties.push(
{ key: 'dg-updated', value: formattedDateTime },
{ key: 'dg_upload', treatment: 'update', value: 'VNC done' }
);
}
// Add or update other properties even if they existed before
properties.push(
{ key: 'status', treatment: 'update', value: 'dg_uploaded' },
{ key: 'share', value: true },
{ key: 'dg-publish', value: true }
);
// Call merge_frontmatter with the properties array
await tp.user.merge_frontmatter(tp.config.target_file, properties, tp);
});
I’ve sent myself on a wild goose chase on this too, actually.
My original YAML keys to do with two types of status were dg_upload_status and status. No matter what I did (a week ago as well, when I wanted to make a processFrontmatter version of my search-and-replace version of one of my key templates), they keys’ values were not updated.
My first thought was it is some kind of Obsidian properties issue again, along the lines of this, meaning that I cannot have properties that has a conflict in names – I even went ahead and changed dg_upload_status to dg_upload everywhere in my vault, when I realized that I need to use update treatment…so finally at least I got it working. But as I said, these two should somehow be merged on keys that can take only one value (if it’s not easy to implement, leave it, just make sure you alert people to the quirks of this).
On date modified, I had to add update treatment as well to make it work. So it works as advertised, is all I’m saying.
There is no ambiguity on Booleans (default add without having to specify anything else works). Didn’t really test tags, as they were solved by you before and I use tags less and less…
2
A minor thing. If the file had no YAML but some content, there was no empty line added after the second instance of ---. In my case I had to add the empty line before my Heading 1 title:
I added this into my Templater js md file:
setTimeout(async () => {
const currentFile = app.workspace.getActiveFile();
let fileContent = await app.vault.read(currentFile);
// Replace if the pattern matches
fileContent = fileContent.replace(/(---)\n(^#{1,6}\s.*)/gm, (match, p1, p2) => {
return `${p1}\n\n${p2}`;
});
// Modify the file with the updated content
await app.vault.modify(currentFile, fileContent);
}, 250);
- This is very rare of course, but I thought I’d mention it.
I hope some of my ramblings made sense. And as I said, I have a hunch some smoothing out still needs to be done under the hood as well before you can finalize the script(s).
Conclusion
The method offered is an upgrade on the formerly introduced methods. I was going to add a GIF here showing my earlier failings using a script from a week ago, but it seemed like too much work.
This definitely seems like an upgrade in functionality on this simpler method, which will not always work as expected, as I mentioned.
P.S.:
I’m going to start updating my templates using this and if in the meantime I see anything, I’ll let you know.
Cheers
