Your game looks very nice 
! Your logic of scenes connections seems to fall into the “metroidvania” genre, but really should work in the same way as in old top down RPGs.
Did you increment the maximum count of proxies ?
Maybe there is a way to achieve what we want through collection factories, by loading the collections dynamically ? Sadly, I don’t think it is possible to unload them from the memory afterward.
You should track the current game state in a persistent data structure, probably a Lua module but possibly also a global Lua table. Both can be persist their data to file on disk as well.
Thanks for your answer @britzl !
That’s what @sicher suggested me too and as I’m sure this solution will work, I’m concerned about the workaround it implies for such a core functionality in the game mechanics.
It feels kind of wrong to add a prefab player spawner to every level I design, but hey maybe that’s the way it is 
Is there any design you would be aware of, that would not imply doing that ?
And while I’m at it. I understand that collection factories could load the collections dynamically. Could this be reversed ? I mean, once they are loaded they are ready to spawn but would it be possible to unload the collections from the memory ?
I am not sure what would be wrong about that. Being explicit often gives major benefits that otherwise would require workarounds (what happens if a level features a different player character? From where do you get the player character on level load? What if the player is not part of an intro cinematic? Do you teleport it to origo during? Etc etc)
Still, you can make life easier if you put things in common for all levels in a collection and put an instance of that in each level.
So basically, if I get you right, you are building a open world game, that’s cool 
There are two things I can recommend you:
Defold has its own RPG Map sample, that teaches you how to create a simple RPG like scene, have a look at it…
I will recommend you using @sicher’s idea, it will be the best way to do things. Spawn the player’ using a factory, store it’s every data in a lua module, even it’s id. And later if you need it’s id, 
you can get it from there. Then create a simple fader script, which fades in and out, and then spawn your worlds, and let your players explore it. This method is extremely good keeping in mind that suppose the player starts one corner of the ground,and then moves to a shop, the next time he comes out of it, you’re expected to spawn it infront of the shop, since you are respawning the player every time the parent scene changes, you can spawn it at the appropriate place directly.
Yes I would completely agree to this way of doing things if there were few big levels, but in my case I will have a lot of small screens connected to each other, so I think I would prefer to implicitly load the player in every screen he visits rather than explicitly.
Thanks for your advices @TheKing0x9 
I looked at it and surprisingly they use collection factories and not collection proxies to load and unload the different screens. So the player is not deleted and created at each scene as @sicher, @britzl and you suggested me.
But I guess as the world is growing bigger, this solution could not be used anymore ?
I’m not sure to get the benefit of this. Moving the player to the appropriate position at screen load without destroying it and respawning it would do the trick too ?
As the worlds grow bigger, it is not that efficient to use collection factories(correct me if I’m wrong) and use of collection proxies becomes cheaper. And the easiest way to place players in proxy generated world is by spawning them.
Anyways you now know the two ways that can be used, it is now up to you to decide which one will suit your needs.
Sure thing. As long as you delete spawned objects you can use collections factories. That will scale.
Ok thanks that is very interesting ! So if I get it right, the difference between collection proxies and collection factories is that collection proxies allocates the memory dynamically is that so ? That means that if I use collection factories all the memory for all the screens in the world will be allocated when the game starts. So maybe even with deleting the collections there will be a time when the allocated memory will grow too large ? If you think not, then what would be the advantage of using collection proxies over collection factories ?
I don’t think so, but correct me if I’m wrong. Collection factories are supposed to work as just a set of normal factories for its game objects and then appling hierarchy, so you don’t know always how many instantiations there will be at the beggining. You can read more about collection proxies here and collection factory there.
Factories set up a static requirement for what’s in the referenced prototype (go or go hierarchy in a collection file). All the resources required for those are allocated and loaded up front. Instances are cheap and created from a pool that is also allocated up front (the max number of game objects as set up in game.project).
I think @sicher explained the situation.
So for what I understand there is two steps for the creation of collections and that is how factories and proxies differ.
Collection factories load the collections automatically (except with “load dynamically”). This means that if for example you have a hundred of collection factories in your game, the needed memory will be automatically required by those factories, even when no instanciation is done. The advantage of this solution is to be able to instanciate the collections at any moment without loading the resources first, which would result in hiccups.
Collection proxies load the collections when they are told to. Which mean they have a smaller memory footprint on your game. You could have a hundred of collection proxies, that would result in a zero memory usage, if the proxies are not told to load. So a great solution to hold whole levels and instanciate them when needed.
This is only what I understand for now so there is certainly misunderstanding of some concepts. If any Defold expert read this I would be happy to be corrected 
The metroidvania logic of scene switching seems to fall somewhere between those two approaches of managing collections. If the world grows too large, the memory footprint of collection factories may become a problem ? (honestly have no idea about this). So maybe collection proxies are a better approach even if they seem to have been designed more for switching whole levels rather than just exploring some areas of the same level.
How many collection would you have? 5, 10, 50, 100?
What would they consist of? You mention “scene switching” but what does that mean? A single screen of gameplay or something larger, but still smaller than a level?
Perhaps dynamic collection factories for these smaller pieces and collection proxies for the entire levels?
Something between 10 and 30.
They consist of small scenes, like a single screen or two. Something similar to “the binding of isaac” or “enter the gungeon”.
Yes I think it is a very good idea and I will experiment this way ! Thanks a lot 
That sounds pretty small. Maybe you can easily fit the whole game in main? How much texture memory and sound do you anticipate this will consume?
It is hard to tell exactly right now. I want my scenes to be self contained so I think I will continue with dynamically loaded collection factories and see if scales well.