I think we can all agree that any mechanism is going to involve coupling; the question is, how much, and what limits does that impose?
The proposed 'use unix pipes' architecture proposed by the original author ('option 1') doesn't bind a daemon to a particular operating system or init system, because it uses a kernel feature common to all unix variants. And of course it itself is a mechanism for passing metadata, so your argument doesn't make sense.
Using a socket would also be fine, and if systemd chose to expose and document that socket API directly, rather than hiding it behind a C shim, that would be tolerable. But since systemd's modus operandi so far has been to attempt to become tightly coupled to every userland component, I'm not holding my breath.
That is not documentation, that is incomplete[1] notes in a man page of a library call. That said, that's getting pretty close to a correctly uncoupled implementation.
The notes define that a socket name starting with @ is a Linux abstract namespace socket, so I don't see where "incomplete" comes from. You can quibble over whether the documentation meets your preferred style (and I'll admit it certainly is odd to reference the underlying implementation in the notes for the wrapper rather than the other way around), but it's a page of text, shipped with the code, that tells you everything you need to reimplement it.
The link I included in my comment shows that the behavior is not actually what is stated in the notes. Do you have any documentation that describes the complete behavior?
oh man, that's a ridiculously grotesque hack. Huh! Thanks! You learn something new every day.
That said, now I don't understand why one would use these things instead of something less openly hacky, like normal portable sockets, which have all sorts of advantages. And I can't find a reason why these were implemented in such a weird and nonportable way. From all I can piece together from the web, it looks like these were implemented by the freedesktop guys for that hacky desktop bus thing, is that right?
Well that's an aside; in any case, having discovered this unnecessary coupling to a hacky linux-only feature, I would go back to the OP's idea of using standard unix IPC, which for the purpose appears to be more than enough to do the job but doesn't bring baggage. Any idea why that would be a bad thing?
Abstract sockets were added to Linux waaaaaaaaaaaay before dbus existed - they were already there in 2.4.0, which is as far back as the history I have goes. You really can't blame the Freedesktop people for them. If your init daemon doesn't run on Linux there's no reason to care about supporting them, either. Write a library that implements sd_notify(), and just leave that bit out.
The proposed 'use unix pipes' architecture proposed by the original author ('option 1') doesn't bind a daemon to a particular operating system or init system, because it uses a kernel feature common to all unix variants. And of course it itself is a mechanism for passing metadata, so your argument doesn't make sense.
Using a socket would also be fine, and if systemd chose to expose and document that socket API directly, rather than hiding it behind a C shim, that would be tolerable. But since systemd's modus operandi so far has been to attempt to become tightly coupled to every userland component, I'm not holding my breath.