Where will UVL put Static Recompilation?

First of all I'll mention decompiling and disassembly, since these can play a role in the process. Normally, source code is compiled into a runnable executable (a binary). A decompiler does the reverse. Source code is created from a runnable executable. Assembly also is compiled into a runnable executable. A disassembler creates assembly code from a runnable executable.

The above processes are for developers and of little concern to end-users/gamers. But Static Recompilation just might be.

As I understand it, Static Recompilation begins with a compiled binary executable (a game ready to run/play) for platform A and uses a compiler to create a binary executable for a different platform (platform B). Several intermediary steps of source code may be involved. Such as, 6502 binary to 6502 assembly to portable C to portable C++ to optimized portable C++ to x86 binary

An example in plain English:
Begin with a PS2 game CD. Create a native Android version of the game. No emulator. Effectively, its a port. With no need to have the original sources.

A few publishers have already used this option.

So for UVL. Worth tracking? Port relation seems appropriate. Tag it staticrecompilation?

That seems like the game (source code and linked libraries) already supported the other platform, so I would think it's just case of "version of" relation. Porting requires actually modifying the code and/or assets or adding platform specific things to the already existing ones to accommodate the new target platform. That static recompilation doesn't seem to need any of it so it's just exactly same thing compiled on the new target platform, thus: version of relation.

However, looking up what static recompilation is (apparently synonym to a type of binary translation), it seems to be what Wine does. It translates the existing binary to target platform's native system, so yeah, it's a port but a specific kind. Wine in this case is a JIT kind of translation that doesn't keep the product around (AFAIK).

But yeah, this is worth noting if it can be validated. Because I don't think such is usually advertised, as it completely lacks accounting for the new target platform's hardware and may result in "bad porting".

Not a factor. The binary code doesn't say "SDL", so decompiling it won't either. It will say hardware the code was meant for, so the static recompilation process could decompile to SDL, OpenGL, or whatever, where the appropriate hardware calls are invoked by the original binary. But the original hardware need never have had SDL or OpenGL libraries.

UPDATE: A Linux executable file (binary) does say "SDL" (for example). At least, it is supposed to contain a table of every dynamically linked library that could possibly be called at runtime. Nothing but the potential outrage of the Linux community prevents developers from making an ELF without this table. Also, GNU compilers and most proprietary compilers will do this without asking the dev, so it's actually a chore to prevent it. But, even though it would be strongly advisable to use the original libraries in many cases, it is not required and it may even be ill-advised is some situations. Trying to go from OpenGL to Wii for instance; where strategic use of native GX2 would work better.

So it's the binary translation stuff that Wine sort of does.

wine does not create standalone Linux binary. Nor does it have an option to derive a source code from the original binary (which can then be optimised and compiled for Mac, PS3 or whatever target chosen).

Yes, but it performs runtime translation for same purpose, it doesn't keep the result as separate native executable but it performs the same function.