If you have the source code, look at editobject.c in
edit_mods, specifically "enter_editmode"
you will notice that when an object is
edited, the "G.obedit" attribute is set to the object type
being edited.. And "G.eded" is a global reference to
the object being edited..
What this means is that when you enter an edit mode, the edit mode is specific to the object, not independent, so to have a multi-object
edit mode, there will need to be another level of indirection..
If blender had been done in C++, there would only need to
be a method for each object that edits the object, then
the edit mode would only need to know a basic subset of
what is needed to edit the object, and check each object's type
before performing the function needing to edit it..
This still can be done in Blender, but it may be made more complex considering that each object has its own transformation matrix (transformation matrices allow parenting to occur, otherwise all objects would be in the same absolute universe).. So it may be harder than you
I think a good go between to solve your problem specifically would
be to allow a object selection mode in group edit mode, so that
the G.eded variable can be changed to match the specific object being
edited, or to have functions that modify the objects as group and
set the globals depending on the object being currently modified.. I
don't know how the problem of the transformation matrices would be handled, particularly if some objects may be multi-parented.. Even
C++ wouldn't get us away from this problem, it has to do with how the
objects you see get there in the first place.. In OpenGL every object is
created in an absolute universe then is applied to some transformation matrices that move the object into space, scale it, rotate it.. And then
its projected into 2D so you can see it on your monitor. To move the object in its own space, what may go on, once you enter edit mode
is the object is transformed into the edit space, you make your modifications, and then an inverse transformation matrix is applied to return it to where it was, and then back again..
It may or may not be this complex, I'm not very familiar with matrix math, but it may shed light on why youa re nto getting an instant response to the solution..
This would be easier.. But I think what you want is a axis toggle
mode, like there is in Maya.. That would be more useful.. I like
blender's current constrained movement option based on the current
orientation.. I personally don't like having to specify the axis
because it causes work to be dependent on a particular orientation,
and its easier to create stuff if you are not having be constantly aware of what is X,Y, and Z.. In Maya you will find a lot of users designing
their objects to be viewed from positive X,Y and Z whereas in blender
any quadrant is your choice, any orientation is possible.. Also
in Maya if you move something on the X axis, if you are behind the object
the object moves in the opposite direction of your mouse, this is unintuitive, unless you really want to do this.. So it should be possible,
but I would suggest maybe something like a constrained movement in a
plane that is aligned with the object oriented to the current viewing
plane, like it is now for a single axis constrain.. So if you view your object
from the front, you could constrain the object to move in one or two axis
adjacent to your view.. This would be easier and more intuitive..
To specify precise X,Y, Z locations, it might be more precise and intuitive to do this as a combined interactive mode on the numeric entry
requester that allows you to increase/descrease X,Y,Z values and
watch the changes made to the object in the foreground.. As well as
to be able to move the numeric entry window move about..
Blender frees stuff upon loading.. So if you save something
out or a blender file is saved out, the stuff is not lost it
is still in the file.. Its freed up upon reading it in again,
so if something is twice indirectly owned and you delete it,
it may take it a while for the object to be deleted.. Objects
are saved unused and then upon loading are not read in (this is
the same as deletion, but probably better because you could conceivable retrieve what you lost upon using a file as a library, which is possible)..
When you delete stuff it offers the problem of if you traverse a data structure that has missing information, there is a greater chance for
crash or a memory leak, or something not getting saved into the file
that is a part of the file.. Like if you deleted an object and that
deleted its material, if the material was being used by another object, code not adequately designed to handle the case where an object doesn't have a material or the material pointer is no longer pointing to a material, then you will have a program crash. In blender, stuff is never deleted, its unlinked.. When its read in, its not read in.. Get it?
The source code for handling of blend files, I looked is in
blenloader/intern , in the sources..
Its possible I guess to have stuff deleted if you somehow have
a piece of memory and use the file save functions to write to the memory, read from it, write, read until the object you want to delete is gone, but this would be the same as what you are trying to do..
I suppose it will be pretty easy to implement, it would probably just be a matter of doing the operation enough to satisfaction, maybe we could call it the shredder..