problem with stabilizer computations when acts differs from gens #6178
Description
Several functions related to group actions support the situation that the action is not described by a custom action function but by some prescribed list acts of elements that shall act instead of the generators gens of the group. Abstractly, one thinks of a group homomorphism that maps gens to acts. This is analogous to the situation with G-modules which are defined by a list of matrices over a given ring, where the matrices correspond to the generators of the group but the homomorphisms are never written down explicitly.
This approach works as long as only the generators are needed, which is the case for example in orbit computations.
However, the operation OrbitStabilizerAlgorithm has a method that tries to delegate work to the perfect residuum of the group G in question, and explicitly constructs a GroupHomomorphismByImagesNC( G, Group( acts ), gens, acts ) in order to map elements of G to the corresponding elements that act, or vice versa.
Technically, this can be a problem because the entries of acts can be something for which Group is not supported in GAP.
(See oscar-system/Oscar.jl/pull/5658 for an example.)
Logically, this contradicts the idea behind the "acts approach": I choose the different elements acts because they are easy to write down, but if I would know that GAP gets the (difficult) task to create a group homomorphism object involving gens and acts then I would perhaps try a different way to formulate the input; the point is that I might have more information about the situation when I call OrbitStabilizerAlgorithm than GAP has when it calls GroupHomomorphismByImagesNC.
Should we perhaps forbid the construction of homomorphisms for gens/acts conversions, and more generally document that the "acts approach" uses only computations with generators, as in the case of G-modules?
If yes then how is OrbitStabilizerAlgorithm allowed to proceed?