Dear Gap-Forum,
dear Leonard,

the answer to your first question is easy:

First query: Can one make a trivial PcGroup, and if so, are all PcGroup
operations applicable to it? My problem is that an algorithm of mine
may produce as an answer a PcGroup which happens to be trivial.

Yes, you can construct the trivial pc-group and pc-group operations
should work:

gap> G := TrivialGroup();
<pc group of size 1 with 0 generators>
gap> Size(G);
1
gap> DerivedSubgroup( G );
Group([  ])
gap> Center( G );                
<pc group of size 1 with 0 generators>
gap> 

Second query: Is there any way of asserting that the type of an object
(say a vector over a given finite field F) will *never* change, in
order that checks do not have to be made if, say, an element of F is
appended to that vector?

It is not possible to fix the type of an object once and for all.
Making this possible would (probably) open a can of worms. However,
careful programming avoids type changes and there is a GAP function
which allows you to determine the exact (internal) type of an object.
Let me demonstrate this in an example.

If you have a vector v of elements in a finite field F, then appending
an element of F should not change the type of v.

gap> v := [1..5] * Z(3); 
[ Z(3), Z(3)^0, 0*Z(3), Z(3), Z(3)^0 ]
gap> TNUM_OBJ(v);                     # get the internal type
[ 30, "list (plain,hom)" ]            # still a plain (homogeneous) list
gap> v+v;
[ Z(3)^0, Z(3), 0*Z(3), Z(3)^0, Z(3) ]
gap> TNUM_OBJ(v);                     # now GAP knows it's a vector
[ 54, "list (sml fin fld elms)" ]
gap> v[6] := Z(3);
Z(3)
gap> TNUM_OBJ(v);                     # still a vector
[ 54, "list (sml fin fld elms)" ]    
gap> v[8] := Z(3);                   # if we leave a whole,
Z(3)
gap> TNUM_OBJ(v);                    # then it's not a vector any more
[ 18, "list (plain,ndense)" ]

The first statement creates a list v of elements in GF(3). At this
stage GAP has not recognized yet that this can be viewed as a vector.
Doing arithmetic forces GAP to check what type of object we have and
afterwards it knows that v is a finite field vector. Assigning
elements from GF(3) does not change this unless the result is not a
vector anymore.

In composing this answer, I realized that there is a problem with the
Add() function as it does not follow that rule. I consider this a bug
and we'll look into it:

gap> v := [1..5] * Z(3);; v + v;;     # produce a vector
gap> Add( v, Z(3) );
gap> TNUM_OBJ(v); 
[ 16, "list (plain)" ]                # darn!

Replacing Add() by an assignment to index 'Length(v)+1' works:

gap> v := [1..5] * Z(3);; v + v;;     # produce a vector
gap> v[ Length(v)+1 ] := Z(3);;
gap> TNUM_OBJ(v);
[ 54, "list (sml fin fld elms)" ]
gap> 

Does this answer your questions?

All the best,
Werner Nickel.