No, it is not an extension, and in fact more a subset. The only difference is that 'position start' is not understood, but any position-go command always has to start with a fen. (Perhaps because 'start' is supposed to be the initial position for Chess, not Xiangqi.) But unfortunately the Cyclone GUI had a bug, sending ' fen' in stead of 'position fen' for each move. Because the Cyclone GUI is very popular, people wanted their engines to be able to play on it, and thus for most Xiangqi engines sending 'position' is optional, and they don't hang if you omit it. That is the only difference.
The S-Chess engine is 100% compliant with standard UCI.
There obviously is a competition here to what info to put in the file, and what info to derive from the path name of the file. In principle you just use empty files, and put all information in the path name, as file and directory names can be arbitrary strings.
But I think using the pathname to encode information is bad practice, and should be avoided if there isn't a special reason why you would want to group the files for access reasons. Othrwise it would just complicate matters for the GUIs, which would have to do a recursive tree walk to find if there is anything you can use. Life would be much easier for them if they could limit the search to just all files in a single directory.
Especially grouping by variant sees a bad idea, because the variant names could be ill defined, and some GUIs might recognize variants that others would have to play as something else, with legality testing switched off. E.g. older XBoard versions did not support Spartan Chess as a separate variant, and had to use the catchall variant fairy without legality testing to let Fairy-Max play it. But newer versions do support it. So if engines that play only Spartan Chess would would then have to put their info file in a directory engines/spartan. But older XBoards would not know what spartan means, and to know that the engine in there is really an engine that uses WB protocol variant fairy to play it, so that it is good for them, would have no way to know that other than opening every info file of every directory of an unknown variant, to see what protocol they use, and if they can use one of their catchall variants to play it. That is very inconvenient.
So it would be most logical to make the primary subdivision by protocol. If an engine is QH, and a GUI supports only UCI, then that is pretty much it, as there is no way it could run the engine. There is no such thing as a 'catchall' protocol. (Of course there are adapters, which from the viewpoint of the GUI are also engines, so they could add their info files in the tree as well.)
Now the directory for a certain protocol, say engines/uci, could be further subdivided by variant. But, as I mentioned, variants are a bit fuzzy. Most GUIs that only support Chess would have no problem to support Losers and 3Checks as well, and perhaps even Suicide. Some variants are pretty compatible, they are not all as different as Chess and Xiangqi.
So I think there is a good case for putting all UCI engines in the engines/uci directory, and declare the variant as text in the info file, so that GUIs don't have to needlessly scan many directories of unspecified names.