While the KDE eclass doesn't set specific homepages per packages, a
number of other eclasses do:

eclass/horde.eclass:HOMEPAGE="http://www.horde.org/${HORDE_PN}"
eclass/java-pkg-2.eclass:	HOMEPAGE="http://commons.apache.org/${PN#commons-}/"
eclass/kernel-2.eclass:HOMEPAGE="http://www.kernel.org/ http://www.gentoo.org/ ${HOMEPAGE}"
eclass/perl-module.eclass:	HOMEPAGE="http://search.cpan.org/search?query=${MY_PN:-${PN}}&mode=dist"
eclass/php-ext-pecl-r1.eclass:HOMEPAGE="http://pecl.php.net/${PECL_PKG}"
eclass/php-pear-r1.eclass:[[ -z "${HOMEPAGE}" ]] && HOMEPAGE="http://pear.php.net/${PHP_PEAR_PKG_NAME}"
eclass/ruby.eclass:HOMEPAGE="http://raa.ruby-lang.org/list.rhtml?name=${PN}"
eclass/xfce44.eclass:	HOMEPAGE="http://thunar.xfce.org/pwiki/projects/${MY_PN}"

Additionally, some of the above eclasses are used by other eclasses: ant-tasks,
java-gnome, perl-app, perl-post, php-ext-pecl, php-ezc, php-pear, gems

A quick scan of the tree shows 15% of the ebuilds do not set the HOMEPAGE
variable in the ebuild itself. And a LOT more qualify, esp. in dev-ruby and
dev-perl. Some quick scanning on groups of packages that I'm aware of puts the
figure beyond 20% of the tree qualifying (converting any dev-perl/perl-core
package that comes from CPAN).

As another major pain, for ebuilds where the homepage changes every version in
some predictable pattern, you have now increased the maintenance burden. Before
we could just copy the ebuild if we had a suitable variable expression in the
HOMEPAGE variable, but now we'd have to edit it into metadata.xml as well.

For all the rest of the ebuilds where it does remain static, I don't see
any actual advantage to removing it from the ebuilds.

To be very clear however, I've got _zero_ objections to adding the extra
new fields into the metadata.xml, provided they are version independent.

-- 
Robin Hugh Johnson
Gentoo Linux Developer & Infra Guy
E-Mail     : robbat2@g.o
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85