I want to continue the discussion to re-instate EGO_SUM, potentially 
leading to a democratic vote on whether EGO_SUM should be re-instated or 
deprecated.

For the past months, I tried to find *technical reasons*, e.g., reasons 
that affect end-users, that justify the deprecation of EGO_SUM. However, 
I was unable to find any. The closest thing I could find was portage 
being unable to process an ebuild due to its large environment (bug 
830187). However, as this happens while developing an ebuild, it should 
never affect users. Obviously this is a situation where EGO_SUM can not 
be used. Fortunately, it does not affect most Go packages, as seen in my 
previous analysis of Go packages in ::gentoo and their EGO_SUM size. 
Furthermore, newer portage versions, with USE=gentoo-dev, will 
proactively warn you if the environment caused by the ebuild becomes large.

All further arguments for the deprecation of EGO_SUM where of cosmetic 
nature.

However, the deprecation of EGO_SUM is harmful to Gentoo and its users. 
To briefly re-iterate the reasons:

The EGO_SUM alternatives
- do not have the same level of trust and therefore have a negative 
impact on security (a dubious tarball someone put somewhere, especially 
when proxy-maint)
- are not easily verifiable
- require additional effort when developing ebuilds
- hinder the packaging and Gentoo's adoption of Go-based projects, which 
is worrisome as Go is very popular
- prevent Go modules from being shared as DISTFILES on the mirrors 
across various packages

Last but not least, we have the same situation in the Rust ecosystem, 
but we allow the EGO_SUM "equivalent" there.

So with portage checking the environment of ebuilds and warning if it 
becomes too large, and with the arguments above, I do not see any reason 
we should outlaw EGO_SUM.

- Flow

Previous discussions:
https://archives.gentoo.org/gentoo-dev/message/1a64a8e7694c3ee11cd48a58a95f2faa
https://archives.gentoo.org/gentoo-dev/message/d78af7f168cef24bfa302f7f75c3ef11