I think this is a no go as I think the current implementation is the correct one!

Current implementation will install dlcservice_util onto base image once we enable dlcservice. dlcservice_util is not necessary on base image.

I don't think so!? Look at
https://cs.corp.google.com/chromeos_public/src/third_party/chromiumos-overlay/chromeos-base/dlcservice/dlcservice-9999.ebuild

We put the dlcservice_util in /usr/local which is only for test images and not base images.
	into /usr/local
	dobin "${OUT}/dlcservice_util"

ah i see. it's not so obvious to me. i agree with #0 to have a dlcservice_util ebuild install dlcservice_util instead of dlcservice ebuild doing everything.

Can you elaborate why you think that's a better option? What is the benefit of that? :)

Some examples that make a lot of executables in one ebuild which, those executables, are not necessarily related.
https://cs.corp.google.com/chromeos_public/src/third_party/chromiumos-overlay/chromeos-base/cryptohome/cryptohome-9999.ebuild

https://cs.corp.google.com/chromeos_public/src/third_party/chromiumos-overlay/chromeos-base/oobe_config/oobe_config-9999.ebuild

If they are separated into two ebuilds, then whenever someone wants to make a change that requires the change in both dlcservice and dlcservice_util, they have to now build two packages
emerge-<board> dlcservice dlcservice_util

which not even takes longer, but also is the source of confusion as both packages should be marked cros_workon start, they can forget to build one and keep pulling out their hair why their change is not being reflected (which has happened to me numerously), etc.

I think ebuilds are there to give us a way to be able to build packages and define dependencies. If a simple solution works, then fine, why to bother making it complicated just to fulfill some non-existent problem? ;)