@greasemonkey I try to not look at this as a difference in opinion because that can shut us off from finding something of value in what the other is saying - like 99% of internet talk I suppose
This discussion allows some people to already find a partial solution that can work for them right now, which is great on its own.
Then others can share why exactly it won’t work for them and this is extremely valuable because let’s face it: there’s a lot of smart people here and those tend to have difficulties dumbing things down, as in their minds the problem is THAT obvious, it’s hard for them coming up with words to fully describe it.
There’s some great insights shared so far by both yourself and everyone else who posted.
For example based on your multiple uses of the words “friction” and “pulling” blocks, I now wonder how people would feel if the problem on how to STORE blocks got solved but we would then always need to type in order to RETRIEVE a block when including it in another page.
Would such a solution still carry the same amount of friction? In other words, when you refer to “pulling blocks”, is it the act of dragging and dropping blocks between documents which contributes to the feeling of efficiency?
Then back to the other side of the coin on how to actually store the blocks in the first place:
I’m sure eventually people will develop multiple flavors of plugin solutions as some want bullets, others want paragraphs, others just lines, etc… and those plugins will be a good fit covering those specific needs.
The risk is with other people not fully understanding some of the intricacies these plugins will bring along when they require storing foreign block indicators inside markdown files.
Everybody can of course accept that risk when using such plugins but nobody wants to see theirs or someone else’s life work get mangled due to the inner workings of a plugin conflicting with another app and/or human error update.
That’s why a fully portable and truly robust solution which can be safely distributed to a wider general audience will most likely need to stay closer to the Obsidian foundation using plain markdown documents.
I’m not a developer and don’t care much for markdown - so don’t know this suggestion is of any use at all, but maybe we need to look closer at using plain markdown without requiring extra foreign indicators in the file?
For instance by using a simple numbered list.
A plugin could validate numbered lists ensuring they are sequential and unique within the document(header). Then couldn’t that regular number be used as the block ID?
Something along those lines would feel more robust to me, easier to comprehend for the average user as well, be portable, and if something does get mangled wouldn’t require the SpaceX team to come in to fix your files.