Regarding the development team’s policy:
It’s a publicly known fact that the priorities of new features, including the number of people who want them, are vague when implementing feature requests. Additionally, we can infer the development team’s view of Obsidian’s core values from other similar FRs. In this regard, I agree that you’re probably right that markdown=good in the context of adding this new feature. However, that doesn’t diminish the significance of this FR.
Regarding comparisons with other apps and the advantages of markdown:
I have no intention of making a common comparison about markdown=obsidian=good. The purpose of introducing other apps here is to point out that Obsidian’s system and workflow advantages are heavily dependent on markdown formatting, and to better define requirements by examining examples with equivalent functionality that can achieve the goals presented in the FR.
Regarding the use of annotations, inline links, tasks, CSS styling, and core search:
Do you mean queries that combine symbols that act as properties with block searches? Or do you mean a method of turning blocks into notes and assigning properties to them? I’d love to see a demo if you don’t mind. Using dataview/datacore is “theoretically possible” but difficult (at least for me), and doing anything beyond displaying search results is even more difficult. I also considered using obsidian’s embedded search, but all it would do is simply display the relevant blocks in the note, and I don’t think it would be able to do any of the organization or further processing shown in FR.
Related links:
Bases: Display, Access (and/or Filter using) the Note’s Content - Feature requests - Obsidian Forum
About the Feature requests category - Feature requests - Obsidian Forum