1.
I think there should be a single step install/enable/mount a set of
packages for some common configurations but I would stop short of
mounting them all that way (or doing it by default). I think you want
to keep the url space clean and there are just too many packages of
varying quality to trust that they will all be free of security holes
and be functional. I think something like the checklist at packages-install for
mounting at cannonical locations would be the most desirable way to do
it (in fact adding a "Mount" checkbox to do this on that page
might in fact be the right thing to do).
2.
Again, I think this is not such a good idea. Partly because of the same set
of concerns raised above and partly because I think the right answer
is to make everything subsite aware and having a half measure like you
are talking about will just forestall fixing all the things which are
currently broken with respect to subsiting.
3.
I looked through how the apm_package_id_from_key was being used and in
most cases where I saw two package_id's could be returned it was
indicative if something wrong with the package (or in the case of
clickthroughs, a shortcoming with our handling of parameters). I
would be more inclined to error out if you called this for a
non-singleton package just so what I see as a pretty common error.
All this exacerbated by the fact that if you type package_id into the
api-browser you will see:
bulk_mail::package_id
which works the way you are talking about, and
bulkmail is not a singleton but the proc is never
called.
rss_package_id
singleton
notification::email::get_package_id
singleton
spam_package_id
singleton although the query handles multiple instances
email_handler_package_id
singleton
all pretty much unneccessary, and also a number more queries embeded
in other procs all doing things in a haphazard fashion.
So assume you make this change...what happens is people go on their
way and use apm_package_id_from_key since it just seems easier than
doing things the right way (or worse they don't even realize this is
not the right way) and then they start complaining about parameters
not being recognized as being changed, permissions being broken, and
other badisms (like things ending up in the wrong folders or under the
wrong subsite).
All not good.
better to add a check constraint on apm_packages to prevent creation
of more than one instance of a singleton and stricter handling in
apm_package_id_from_key and fix the few bugs that manifest as a
consequence.