[MysticLord]

I'm curious how they found this out, and if other rereleases/masters like Romancing Saga 2 and 3 are the same or not.

[Lenophis]

Pretty much every re-release to a new port for the old console games are emulated to some extent. FF4-6 and Chrono Trigger for Playstation back in the 90's? Emulated. Steam ports? Emulated but with "updated" graphics. Various Genesis Collections are all emulated. The Mana series re-release for Switch/Steam/PS4/et al is also emulated.

I could go on.

Very few receive actual work to be a new game. This is where Link's Awakening for the Switch, Trials of Mana for the Switch, Sword of Mana for GBA, etc come into play.

[Jorpho]

FF4, at least, apparently contains the original GBA ROM in its binary data. I don't believe that's the case for the other two, though.

[tc]

On its own it's just data. While unorthodox, ROMs can be used in any number of ways that are not emulation.

[Chronosplit]

Square's been using emulation shells for a very long time.  At least ever since the Final Fantasy Tactics iOS release many years ago, that's why at the time the specs were sky high and the animations are currently sped up.  They may have even done that since the first iOS release that was (and still is) a stripped-down PSP version of FF1.

It's just predicted at this point.  It's cheap, it's easy, it's available.  Along with how many of their PC ports are rooted from mobile.

[FAST6191]

To answer the more abstract question.

Assuming you don't want to go right in for pulling apart the code (though check to see if they have not credited an emulator author as many will buy one in)

Step one is check the files of the game and compare it against known ROMs/other versions.
This usually gets you most places but sometimes they will not use a ROM as known by the Scene/emulation/flash cart/preservation communities and instead use a nice interleaved format, encrypted format, maybe inverted format or possibly compressed (unlikely for most things known as a ROM rather than ISO but it is an option). I have not seen this so much in recent years but if the original devs have say files as they would have been presented to cartridge makers rather as dumped/seen by the host machine (possibly with a scene/emulator driven header to note extra info) then it might be using that.
As mentioned above they could still be using the ROM as a glorified archive file for some of the assets, possibly recreating the code itself at a higher level, and at the same time they might bring their own extras (say music files, though that can also be that they don't want to emulate an audio core).

After this you might want to check known bugs, especially if they are simple programming error rather than more abstract balance issues. Now it might have been a lazy recompile still but it is a good start.

Graphics can give it away (if they use original size, or simple scale, and don't have nice say widescreen options in the modern world* then something to consider) but they can just as easily do a glorified real time texture replacement if they deem it necessary. Likewise if there are symbols or button names for an old console that is a giveaway of a truly lazy emulator effort (a basic font/graphics hack should not be beyond most would be coders).

*a lot of 3d based consoles can actually get widescreen quite simply by just widening the virtual camera, and maybe tidying up some overlays or triggers based upon it, so keep that in mind.

Odd approaches to saving that you might not expect for a current console or PC might also be something, though that could also be them "keeping to the spirit of the original game".

Strings (many hex editors will have this) and function names dump ( https://www.dependencywalker.com/ is a program that might do something here, plenty of others though https://alternativeto.net/software/dependency-walker/ ) of the program might also yield some indication of emulators being the order of the day.

Inaccuracies associated with emulators could be something to look for next, gets a bit harder if they made their own emulator but at the same time if they made their own they might not have taken the hard won lessons from the larger emulation scene and made a "it'll do for this game" emulator.

After this then probably time to start looking at code to see how it operates. Emulation, especially of older systems without dynamic recompilation (though dynamic recompilation is itself not necessarily lacking in distinction), is fairly obvious in code vs how a game would normally work. This is to say most programs go off and do their own thing with functions, OS APIs and whatnot**, where emulation will be a simulation of a machine itself and probably constantly referencing the would be ROM. Dynamic recompilation will tend to be fairly obvious as well but might look similar to just in time compilation (common in scripting languages, things like Java and some other languages) so might need more than a glance. That said Java, scripting languages and the others tend to have fairly telltale signs as well as far as file names, extensions and headers that most devs would not think to hide. Even if you are fiddling with assembly then you don't necessarily need to know how everything works, just enough to get a sense of the program flow.

**technically you can probably do something like play with ofview https://www.nirsoft.net/utils/opened_files_view.html if you don't want to break out the debugger right that moment and gain some useful info.

Generally speaking though despite what https://www.gdcvault.com/play/1023470/-It-s-Just-Emulation and https://www.gdcvault.com/play/1025782/It-s-Still-Emulation-Saving have to say then emulation is not exactly a dirty word and most devs are not in a hurry to hide it.

[MysticLord]

To answer the more abstract question.

Assuming you don't want to go right in for pulling apart the code (though check to see if they have not credited an emulator author as many will buy one in)

Step one is check the files of the game and compare it against known ROMs/other versions.
This usually gets you most places but sometimes they will not use a ROM as known by the Scene/emulation/flash cart/preservation communities and instead use a nice interleaved format, encrypted format, maybe inverted format or possibly compressed (unlikely for most things known as a ROM rather than ISO but it is an option). I have not seen this so much in recent years but if the original devs have say files as they would have been presented to cartridge makers rather as dumped/seen by the host machine (possibly with a scene/emulator driven header to note extra info) then it might be using that.
As mentioned above they could still be using the ROM as a glorified archive file for some of the assets, possibly recreating the code itself at a higher level, and at the same time they might bring their own extras (say music files, though that can also be that they don't want to emulate an audio core).

After this you might want to check known bugs, especially if they are simple programming error rather than more abstract balance issues. Now it might have been a lazy recompile still but it is a good start.

Graphics can give it away (if they use original size, or simple scale, and don't have nice say widescreen options in the modern world* then something to consider) but they can just as easily do a glorified real time texture replacement if they deem it necessary. Likewise if there are symbols or button names for an old console that is a giveaway of a truly lazy emulator effort (a basic font/graphics hack should not be beyond most would be coders).

*a lot of 3d based consoles can actually get widescreen quite simply by just widening the virtual camera, and maybe tidying up some overlays or triggers based upon it, so keep that in mind.

Odd approaches to saving that you might not expect for a current console or PC might also be something, though that could also be them "keeping to the spirit of the original game".

Strings (many hex editors will have this) and function names dump ( https://www.dependencywalker.com/ is a program that might do something here, plenty of others though https://alternativeto.net/software/dependency-walker/ ) of the program might also yield some indication of emulators being the order of the day.

Inaccuracies associated with emulators could be something to look for next, gets a bit harder if they made their own emulator but at the same time if they made their own they might not have taken the hard won lessons from the larger emulation scene and made a "it'll do for this game" emulator.

After this then probably time to start looking at code to see how it operates. Emulation, especially of older systems without dynamic recompilation (though dynamic recompilation is itself not necessarily lacking in distinction), is fairly obvious in code vs how a game would normally work. This is to say most programs go off and do their own thing with functions, OS APIs and whatnot**, where emulation will be a simulation of a machine itself and probably constantly referencing the would be ROM. Dynamic recompilation will tend to be fairly obvious as well but might look similar to just in time compilation (common in scripting languages, things like Java and some other languages) so might need more than a glance. That said Java, scripting languages and the others tend to have fairly telltale signs as well as far as file names, extensions and headers that most devs would not think to hide. Even if you are fiddling with assembly then you don't necessarily need to know how everything works, just enough to get a sense of the program flow.

**technically you can probably do something like play with ofview https://www.nirsoft.net/utils/opened_files_view.html if you don't want to break out the debugger right that moment and gain some useful info.

Generally speaking though despite what https://www.gdcvault.com/play/1023470/-It-s-Just-Emulation and https://www.gdcvault.com/play/1025782/It-s-Still-Emulation-Saving have to say then emulation is not exactly a dirty word and most devs are not in a hurry to hide it.

Thanks. A guy in my Discord claims that RS2 and 3 rereleases were engine recreations in Unity, and seems to have a better grasp on the subject than I do. Thanks for helping me maybe win an internet argument when I look into it.