About the second question, if it is possible to write a problemtype in Python.
The .spd (customlib) or .prb, .cnd, .mat, .uni are not any programming language (I don’t consider XML as a language)
They are not Tcl or Python.
But from these description files GiD is building its GUI tools: the tree and different windows, and all this is implemented in Tcl/Tk, not in Python (but is implemented by us, the GiD developers, not by a problemtype developer or its final user)
About writing the calculation files, instead use a Tcl procedure technically is possible to write a Python procedure, but I don’t recommend it at all: The Python function will ask GiD its information through Tcl in a similar syntax that doing directly in Tcl. Can reorder this information and print it with its methods, but doesn’t has any advantage compared with the Tcl alternative (if fact has a several drawbacks to debug, performance, etc.)
About changing the GUI and creating new windows, Python is a pure console scripting, like Tcl. And all GiD GUI are Tk objects, Python has nothing to do with it (at least better than Tcl). Maybe using the TkInter Python library is possible, but in any case this is a wrapper of the true Tk library. (why do in in Python that call TkInter that call Tcl that call Tk. Is is better use directly Tk)
The main current use of Python in GiD is for console (non GUI) features.
To have access to his big amount of available modules that can to a lot of things not available in the Tcl small ecosystem (e.g read medical image formats, use other NURBS libraries, other CAD libraries, Artificial Intelligence libraries,…).
Or to avoid to rewrite you own existent Python code in Tcl to be used in GiD.
It is possible from tcl call Python procs and vice-versa from the Python interpreter call commands of the Tcl interpreter