Most of these kinds of questions have to do with feasibility, where the question asker doesn't have all the context needed to:
1) Decide: is this worth it for the business? NOW?
2) Delegate: ok, we've decided it's worth it NOW. Who is best equipped to execute?
So, that's not a "bad question."
Most of the time, saying "no" also comes with helping the requester de-scope to meet the crux of their obligations, save face on any commitments they won't be able to meet.
Saying "yes" means figuring out what the work will displace.
A significant part of my job as a staff infrastructure engineer was carrying this kind context between planning rituals with various time horizons, ranging from weekly to quarterly to annually.
Occasionally I would drop down into execution mode myself to knock out something particularly gnarly, or set up some pins for someone else to knock down (e.g. promo season).
I've developed a distrust for anyone who hates on systemd in 2022, especially if their rationale is vague dogma like "it does more than 1 thing, it's not Unix-like!"
It's usually a signal that the person is not a practioner.
Systemd is the most important and well-developed Linux framework, besides the Linux kernel itself.
> Unfortunately most software is just not well defined up front.
This is true, and I think that's why TDD is a valuable exercise to disambiguate requirements.
You don't need to take an all/nothing approach. Even if you clarify 15-20% of the requirements enough to write tests before code, that's a great place to begin iterating on the murky 80%.