pkgng default schedule... registering a few reasons for rethinking the final implementation...

I am following with dread the planned implementation of the deprecation of /var/db/pkg as a package registry... I use each /var/db/pkg directory as a database into the port installation/status, using sed/grep/portmaster/portmanager/.sh scripts/find/pipes etc... to fix stuff.  For instance, an upgrade py26 > py27. 
cd /var/db/pkg
ls -lac | grep py26
ls -lac | grep python
as the more simple example. 
....
With due respect to its developers and the persons who agree that
the package tools could be upgraded, the mandatory 
usage of a front-end database to a file directory one
is here viewd as mutt-only-mbox, registry-and-bsod rather
than /etc/local/rc files, deprecation of sed/grep/find/locate/.sh/portmaster/portmanager as tools to fixup/upgrade the ports that are registered;
...
I see concurrently too few tests on lower-end p2, p3 as to whether
pkg can run with lesser memory machines (routers...) (pfsense)
...
I suspect stalling of successful frontends to bsd (pc-bsd, ghostbsd,
pfsense..) due to less-reliability, more-possibility of bugs..
...
Not to mention native tab-completion not dependent upon further
customizations, 
...
Introduces complexity to running earlier versions of BSD virtualized
in later versions and vice versa...
...
I've innumerable times made "quick work" (2 hours or so) of 
cross-disk backup/fix/upgrade using /var/db/pkg where doing so
with just the pkg tools or my own scripts would take immeasurably
longer...
...
It would deprecate searching +CONTENTS, for example, or quickly
checking the text file +REQUIRED_BY without a database frontend.
...
Almost every reply and post have glossed over those points, referring
to the benefits of a newer package management system, again glossing
over the added memory requirements, number of .so. required, lack
of extensive testing across all hardware cpu/memory scenarios...
...
"it will be a single tool that will do the job of all the
many port/package management scripts currently only available
in the ports system (bsdadminscripts)"  for example.  A single
tool, yes. But it won't do all of the edge-case jobs *not* covered
by the present pkg_ tools that can be crafted hooking into the
/var/db/pkg/ directory structure, with find for example.
"pkgng is not a replacement for portmaster or portupgrade..." That
was not my question.  My concern was with the deprecation of 
the latter and /var/db/pkg along with the introduction of pkgng.
...
Each pkg_ legacy uses about 3-6 .so. afaik.
pkg uses 19.
...
A review of pkgng on mebsd.com, suggests replacment CLI for tasks
one might do with portmaster now. However, they are much more 
arcane (%H-%M vs -g...) and thus unwelcoming...
...
"patches for portmaster and portupgrade to use pkgng tools"
Memory requirements with both working together?
The ABI between them breaks?
...
My concerns are more or less, why should the following *ever* be
mandatory...
"On both FBSD 10 boxes, the installation of the port security/cyrus-sasl2 got
corrupted by "install" and/or "mtree" dumping core and signalling
SIGNAL 11.  Booting into multiuser mode is impossible, login core
dumps SIGNAL 11, many other daemons, too.  The only way is to boot
into single user mode.

An installation failed due to pkg(ng) was missing libarchive.so via
portmaster or via core dumping install. By installing on one box,
my home box, port security/cyrus-sasl2 manually, luckily install and
mtree didn't coredump and it worked - and this procedure rescued me.
But on my lab's development box, it didn't work! "
(Continues with more equally terrible detail...)
(Freebsd-questions, august)
...
Or my own experience, today, testing on a p4 pre-p2 memory req.
investigations.
# pkg stats
Unable to open remote database "repo". Try running 'pkg update' first.
# pkg update
Updating repository catalogue
zsh: segmentation fault  pkg update
.............
So, a kernel option (non default) to deprecate /var/db/pkg?
A further development of pkg to concurrently maintain a /var/db/pkg?
   ...not implying the concurrent deprecation of the latter! 
Brighter ideas? 

Thanks for reading these concerns.  I am quite perturbed by the
announcement of v11 erasing the /var/db/pkg upon which I presently
use daily numerous times...
And I apologize, in advance, for typos etc. herein...

J. Bouquet
2004 v5...