Everytime someone uses the word "engine" in relation to a component of a game, the word loses a little meaning. The term was invented in the Doom days; imagine how much meaning it has left.
Right. Not much.
"Game engine" used to have a well-defined meaning. Nowadays, "engine" is just an overblown synonym for "library" or "module".
The "Rendering engine" is nothing more than that part of a codebase which is told where to draw stuff, and that stuff gets drawn there. The "Rendering engine," in a well-architected game (hard to come by, I know) has no knowledge of who tells it what to render or where to render it. All it cares about is doing the rendering.
The "Physics engine" is again simply the part of the codebase that decides how things move around and whether they collide. It should not know or care how this information is conveyed to the user. A well-architected physics engine should not have any particular dependencies on the rendering engine, or even know that it's feeding a rendering engine. It just moves stuff around.
The "Game engine" is a concept so nebulous as to be non-existent.
A "Scripted game" (one of these things is not like the other) is a game that has scripts that control some aspect of it. Which aspects is up to the game developer. Some games expose the renderer directly to the script, thus coding most of the game in the script. Others only expose basic things like the ability to spawn entities at fixed, predefined locations to scripts. Most are inbetween. Obviously, some don't even have scripting to begin with.
Ultimately, none of these modules needs to have any relationship to one another. They can be said to be hierarchically composited, but none of them needs to know that the other exists in order to do their jobs.