When you move out of the layout, you will lose everything except those that are Global objects. Usually Sprites are not Global by default; you need to turn them on. It depends on the nature of the pickups or how many Sprites you want to remain for you to manage.
In regards to persistent pickups: I would like to suggest working with a 'database' of objects that you expect to be in a layout. This 'database' is actually a Dictionary, which are Global, so they persist. They are saved when you 'Save Game', so that's bonus.
The Dictionary contains information about the item, for example. its default location, and its state/status (eg 'default', 'pickedup', etc) and whatever seems relevant to you. This Dictionary defines how the item will be displayed, if it were to be displayed at all.
So for example, I have a Dictionary object called 'ItemsDict'. ItemsDict has an instance variable called `owner`. `owner` refers to the House that will refer to this dict. When I have ItemsDict.owner=House_A, this means that the items that will be contained in this dict are items from House_A.
Then imagine we instantiate another ItemsDict and assign `owner` to House_B. So now we have 2 dicts.
Now when we enter a layout, we pick the appropriate ItemsDict using the owner name. You may use the layout's name, or some other mechanism. Once you pick the correct ItemsDict, you cycle through all the keys, and instantiating new Sprites that correspond with the data inside ItemsDict.
When the player has interacted (eg picked up) with an Item, you have make sure that ItemsDicts is updated first by removing the item/key or changing the values, or whatever is appropriate. Perhaps your update mechanism (ie the one that controls the visibility/presence of Sprites) should always derive its state from ItemsDict so that you only have to change ItemsDict and let your updating mechanism handle the visual updating of the scene.
If you exit the layout the Sprites will be destroyed, but ItemsDict will remain. Then go into House_B layout, the same process applies; Sprites are recreated using ItemDict.owner=House_B. But when you go back to House_A layout, the Sprites are recreated, but the objects you've taken will no longer be in the dict and thus won't be created. And that's how you may approach persistence.
Re portals: the player character, whether it is encapsulated as a single Sprite or multiple Sprites, I recommend to be Global because it's usually efficient as the player is the most consistent element from layout to layout.
First, I suggest creating an instance variable in the player called something like `portal`. This makes you avoid the use of global variables.
The concept is having an 'outbound' portal and an 'inbound' landing area. These are two different Sprites. The 'outbound' portal has 2 instance variables called `layout` and `landing`, which is the name of the layout and landing id, respectively, that this portal is going to deliver the player. The 'inbound' landing Sprite has only one instance variable called `name`, which is its identifier.
For example, inside a House_A, there's a portal with `layout=FirstAvenueLayout` and `landing=House_A_entrance`. In the layout FirstAvenueLayout, there is an 'inbound' landing Sprite with the `name=House_A_entrance`.
When the player goes over the 'outbound' portal (ie is overlapping object), the player acquires the `landing` variable value and puts that value into its own `portal` instance variable. This tells the player that whatever layout he ends up in, he will always be placed on the 'landing' Sprite with the same name. In this case it's 'House_A_entrance'.
The System, on the other hand, will acquire the `layout` variable of the portal, which tells the System to move to that layout. When the layout is loaded (ie On Layout start), the player looks at its`portal` variable and finds the 'landing' Sprite and positions itself there.
It is important here to make sure that when you 'land' at a place that it is not in the same place as an 'outbound' portal, or else you'll keep on bouncing back and forth. You may place other event conditions that prevent this, of course.
Hope that made sense.