So I'm writing my own engine for fun, and I want to have several games using this engine but I'm not sure where the program initialization code should live. Should it be present in each game project, then the game passes system events down to the engine? That seems incorrect to me, but if I have main in the engine, then how does the project know which game I'm trying to run?

I want to link my engine to my game statically, and I want my boilerplate application initialization code to be in my engine. But I want to be able to compile my games as separate executable that link against my engine. I'm unsure how to achieve this decoupling with all of these properties. Does anyone have any advice?

No, do not include your own main. What if someone wants to compile your engine as a lib and import it? For example to run the game engine inside of a level editor or UI. Maybe someone wants to run your game inside of wxWidgets. In this game wxWidgets needs to call a function and pass a function pointer, something like:

DoGame( user_data_ptr ); 

The best practice is to expose your engine through C functions, this way it is easy to compile the engine as a static library, or a dynamic library, or by copy/pasting source code directly into a project.

What Hodgman said is basically how ID tech worked (I don't know if the recent version continue on this road).
What you can do is to have one Game.exe compiled, and do all with loading of scenes and then you only have scene which launch script, all script based.
So basically you have a way to say the start scene and then all other scenes are loaded from this one using script and gameplay using script as well.

I have had a lot of research on this topic just before setting up my engine because I wanted the perfect repo structure, the perfect code clearness and perfect speed. Now I now that there isnt something perfect just that what you are willing to work with or not work with.

One of the results I'm very happy with is to compile anything from the framework/engine code into static linked libraries that has the advantage that you could easiely modulate your code. I have set up everything to be as most standalone as possible but also capable to use the full power of any module that exists. When a module uses functions from another one it is not a problem to make a static linked library from them because linker will assemble anything into the executable correctly (Tested in MSVC 2010/2015, GCC LLVM)

To setup a new project a need just a build file where I specify whatever module I want to use and run the tool from the engine directory that setups a VS project for it even when I have also seen a lot of copy/paste project setup or starting a project from a tutorial of the library we then used, I think this is something more clean to get it.

In my system I have a macro that setups the typical main call for targeted platforms requireing an init, main and cleanup function to be called. In the engine I'm currently working on there is a file Engine that contains static functions in a namespace that setup memory management and clears it after anything is finished running. These two functions are put into the macro so that

int main(Array<const char*> const& args)
{
  return Engine::Run();
}
__app_entry(Engine::Initialize, main, Engine::Cleanup)

is anything that the executable needs to call to get the game up working. The Run function then takes control over the OS specific message loop, queries main thread of the job system and registeres a small event callback to shutdown everything properly; thats it! And in my opinion it is enougth because anything else like loading config settings into the engine or register systems at the task manager has to be done before Run.

The rest is scheduled by the task manager when the system is setup and running regardless of if it is an engine system like rendering or something gameplay related like character controller.

I also decided a completely data driven approach like old TES Oblivion did where replacing the main .bsa file meant to have a completely new game (what some modders did) but the decision against it was simply performance related where having anything in scripts may be a critical impact.

I'm happy with it because it is as generic as possible and also as near to the engine code as needed. Maybe you might think that there is something that better fits your needs