I’d suggest avoiding this approach. Logseq’s attribute format is not well-specified and depends on parsing conventions (such as requiring a newline) that are not reliably handled outside of Logseq itself. In practice, only the Logseq parser can round-trip this format safely.
Adopting it here would introduce fragility and effectively add another ad hoc convention for representing properties in SilverBullet.
More broadly, one of the advantages of storing data in Markdown is that it remains easy for users to transform and adapt as needed. If interoperability with another tool is desired, it’s more reliable to handle that through explicit conversion, rather than embedding support for loosely defined format. Especially since interoperability with other tools is not a primary goal of SilverBullet.