Ludo will stay smaller than RetroArch by only implementing the core features and by targeting less platforms.
By not adding advanced functionalities we aim to deliver a stable frontend for beginner users on Windows, Mac OSX and Linux.
Some design choices are different, for example we support less cores, and choose cores for the user. The cores are packaged in the frontend so no additional step is required to launch a game.
As RetroArch, Ludo is a libretro frontend, so the way of communicating with the emulators is the same.
Same cores, similar UI patterns, joypad driven UI, same game thumbnails, mostly the same game database, same terminology. I think we can also say same developers, as I am an important contributor of the libretro team, and all the people who provided me with help are also member of the libretro community.
It definitely shares the same values.
To keep a software stable on a number of different platforms, it is important to keep a small codebase with a good test coverage. It is also important to not introduce changes at a high rate.
RetroArch is an extremely active project and has a growing codebase that makes it harder to reach stability.
Also, RetroArch is a very powerful and sophisticated frontend, and one of the common criticism is that it exposes too many configuration options for the average retro gamer.
Implementing Ludo as a menu driver of RetroArch would solve none of these issues.
No, the scanner logic is basically the same and Ludo supports even less ROM formats.
CDs are scanned based on file name instead of serial number.
Ludo's scanner faster for this reason and because it leverages goroutines.
The answer is likely to be no, as we're trying to keep the code small, only bugfixes are really welcome.
We encourage you to fork Ludo and add the feature yourself. It should be fairly easy given the scope of the project.
If you are able to author a very useful improvement with a minimum of changes we might merge your change.