Overview:
The number of rooms in POH is limited (for obvious reason). Even after last update it will be hard to create really impressive castle or dungeon. More increase of player's room cap is probably not technically possible, but there is still one way how to allow creation of bigger houses and dungeons - allow players to get their lands together. Even if we limit this group to just 4 players (to simplify group maintenance and also to prevent server overload) then such group of players with average construction lvl will be able to make house with about 100 rooms. With 100 rooms available players will sure be able to create impressive things.

Suggestion:
The basic idea is to allow players to join their houses to one group to allow making of more complex houses. There are, however, some basic problems to be solved:

1)	creation of group, picking new members
2)	positioning of lands
3)	leaving group
4)	kicking out group member
5)	losing group member
6)	moving and redecorating of houses in group
7)	working on outlands, using in-house equipment, servants, ...
8)	controlling access to house
9)	accessing group of houses
10)	creating (loading) instance of group of houses
11)	group of houses build mode

Here are some basic terms:

Group	group of houses or group of owners, depends on context
Member, Owner	player, owner of one of houses in group
Land	area in group of houses owned by player in question
Outland	area in group of houses owned by other players then player in question
Border of land	The smallest possible virtual rectangle having inside all rooms on land regardless of level of house.
Freeland	area in group of houses not owned by any players in group. All squares located out of land borders. Can be "claimed" by any player able to move border of his land to this zone without conflicting with other land in group (border of land should be rectagular).

creation of group, rules:
The first task in creation of group is to tell system what lands we want to bind together, where we want borders between and how we want to have them positioned. Other problem are rules and conditions required to allow binding of lands. To simplify things, both location and decoration should be the same before binding of lands. Both lands or group of lands should have Group Border Mark (GBM) object defined and these objects should match each other without conflict (see explanation of GBM bellow). One land (or group of lands) should be loaded in NORMAL mode and the second land (or group of lands) may not been loaded at all (beware of visitors and other members). Both owners of GBM objects should be inside loaded house and there may not been any other player. Total number of lands in both groups may not exceed limit of 4 lands (it will be possible to join two groups of two lands or to join one land to group of three but binding group of two lands and group of three lands will be rejected).

Group border mark (GBM) object:
Probably the best solution for binding and positioning lands will be use of special Group border mark (GBM) object able to be build on door hotspot instead of new room. Each house or group of houses can have just one GBM built at time. Full group cannot have any, however. GBM can be build only by land owner the door hotspot belongs to but because there can be just one GBM per group, it can be removed by any member of group by special button in POH control panel (requires "are you sure?" confirmation, however). GBM can be built only on border of land and if GBM exist no room can be built on land that goes over this "border". This rule apply also to outlands in case of group of lands. So it is not possible to build GBM on hotspot adjacent to existing outland and any existing outland cannot move its borders over existing GBM object. GMB can be placed on ground lvl of house only. This will allow to position lands to have door hotspots with GBM objects defined binded together. Built GBM will look like obelisk placed outside door hotspot. The owner of matching GBM object can select "join lands" option from right click menu. It will first make test of possibility of land binding. According to results will player either get error message describing cause of failure or it will open confirmation screen for both GBM object owners. After confirmations the lands will be binded together and whole group will be reloaded by RS clients moving players to their exit portals. Both GBMs will be destroyed by this process.

positioning of lands, matching rules:
To join houses to group, their GBMs should "match" correctly - it means that, for example, if one player will build group mark on west side and other player on east side of their lands, system will be able to match group marks together and position border and houses exactly like players want. But if one player will build GBM on west side and other on south side, join is not possible.

Even if directions of GBM match, join is possible only in case there is not any conflict with outlands. Let say that we are joining fourth house to northeast corner of existing group of three lands positioned to simple L shape and that we will build GBM on south border on third room from west. Owner of southeast land will build GBM on north side of its land and he use second room from west to do this. Such join is not possible. Land we are trying to join will have most west room on the same place like most east rooms of northwest land in group. But if we choose second room from west and owner of southeast land third room from west, join will be possible and there will be one room wide freeland between our land and northwest land we both can "claim" by building room in it.

According to my Advanced door space suggestion I need to add "adjacent door hotspot content compatibility" rule. The border between two adjacent rooms is very thin and it is partially shared by them. The same apply to doorspace. While it is possible to control combatibility of hotspot content during building phase, in case of binding two lands together there can be hotspots with existing content that will be positioned to incompatible content of other land. Actual door hotspots have not any content so they are sure compatible from this point of view. But if there will be any content available, those content should be "compatible" to allow binding of lands on this hotspot place. Empty hotspot is compatible with everything, solid wall type of content is compatible with any other solid wall type content. But if there is door or gate type of content, the matching hot spot should be empty otherwise it will be hard for game to decide what content should be used on this shared place.

leaving group:
The life is constant change and no party can last forever. If player can join group of houses, he should be also able to leave it. In addition to player's own will, there are also other players in group that can decide to kick one member out and Game owner (Jagex) can place some restrictions here in case player is banned or in case his membership is over (POH is members only feature). The simpliest thing is to leave on players will. There can be just another special button in POH control panel (again with "are you sure?" confirmation) that will allow player to simply leave actual group. To do this he should be the only player inside house. After this action his house will removed from group and then it will be reloaded (he will be moved to his exit portal). If group has just two houses, it will be destroyed if one of them leave group.

kicking out group member:
There are good neighbors and neighbours that are ... not so good. People changes over time and sometimes can happen that they suddenly want not to be in the same group as other player. But what to do if such player do not want to leave himself or if he is not available for long time? Ok, it is always possible that other players leave group and make another group without player they want not to be in anymore. But this solution can be expensive (if GBM be charged a lot) and it also means that all members of new group should meet online one by one face to face to make another group. In this case some method how to kick other member can come handy. In POH control panel will be KICK button that will open list of other members. Player can select one and confirm to create kick request. Other members will be then noticed when entering house that there is pending kick request - they will obtain message like "player X requested kicking of player Y, remaining time n hours". If any other member will press KICK button and confirm this request, the target player will be removed from group. It will also kick out all players from loaded house to be able to reload group. Only one kicking request can be active at time. It is time limited to 24 hours and if it is not confirmed at time it will be rejected (means that target player will stay in group). The same player cannot create new kicking request until another 24 hours passed. If requesting player or target player leave group before request is confirmed or timeouted, request will be dismissed. Requesting player can cancel it anytime but 24 hours restriction to create another request will still apply.

losing group member:
And now something a bit different. If one of members lose membership (or be banned, the effect is the same), his house will be kicked out of group automatically on next loading of group. Theoretically it is possible just to "hide" such house and left his space in group "reserved" for period of time player is unavailable. Other members of group can kick such player manually if they want. But I think that kicking solution is much easier to implement and if player renew or reclaim his account it is always possible to rejoin group.

moving and redecorating of houses in group:
Ability to move or redecorate house is given by construction level of the worst member of group. Action itself is in responsibility of the member with the best construction skill in group according to hiscores database. If there are more players with the same construction level and experience points, all of them have this right. Both moving and redecoration is not possible if group of houses is already loaded (ie. anyone is inside).

working on outlands, using in-house equipment, servants, ...:
To prevent RWT and other abusing of POH grouping, working on outlands is not allowed neither using of servants that belongs to other owners. It is alowed to use in-house equipment on outlands like if it is normal friends house. It is possible to use outland equipment in both normal and build modes (see more details about group build mode bellow).

controlling access to group of houses:
Access to single house is controlled by single owner, its private channel setting, friend list and ignore list. And single owner is also possible to kick all guests out of his house anytime. But for group there are 2-4 owners and each of them has different friendlist and settings. On other side, guest is accessing house by typing "friends" name. It means that the same rules can apply like for single house, but guests has now ability to enter house even if they are on ignore list of one of owners in case that other owner will let them in. Guests will be moved to exit portal of owner whose name they used to enter house. They can then move over all houses "freely". If my other advanced door spaces and portal ideas be applied it will be probably possible for owner to lock shut all portals and doors in his house so no guest of other owners will be able to enter it.

Group of houses also needs one of long requested features - ability to kick individuals out of house by right click on player. Only house owner can do this, can kick people only from his land and cannot kick other owners. Kick guest button in POH cotrol panel will now have two functions displayed on confirmation screen - kick guest from your house only and kick guests from whole group. Lock house/portal function will just lock portal but it will not kick any guests. This function can be again used as local or global. Global lock will lock portals of all owners for all guests. Other owners can enter house even if there is global lock and they will be informed about it by game message. They can remove global lock anytime regardless of who did it.

house combat mode is global feature and any owner can change it on its own (if he owns lever, however).

accessing group of houses:
Accessing house by guest is not big problem as house is loaded on right place or not and guest has access rights or not. But in case of owners it is way different problem because members of group can play on different servers. This means that house, player is trying to access, can be already loaded on different game server. It is most serious problem of this suggestion. Unfortunately, any complex solutions depends on unknown technical backround. The best possible solution will be to make special (even virtual) server(s) for group instances that will allow players from different servers to enter running instances, keep them logged in on game server they came from and on leave it return them to right world. You can imagine complexity of changes required on game servers side for this solution. On other side, grouping of houses will require some deep changes anyway and moving big part of code to fresh new server can be easier then implementing all changes to existing game servers structures.

There is, however, simplier variant. While the information of single land can be saved the same way like it is now, it is not enough for grouped lands. The information about houses in group and their positions should be saved somewhere else anyway. Probably on special shared server similar to friendlist or clanchat. Such shared server can hold not only "static" information about members and positions, but also dynamic information about house owners - on what server are they actually playing and on what game world is group actually loaded and i what mode. When member tries to enter house portal, this server will be asked and if group is already loaded on another server or if it is loaded in different mode then player is asking for, player request will be rejected. It means that player cannot enter his own house in case it is loaded on other game server or in different mode by another member of group. Player will get information about server number his house can be accessed on and in what mode.

It sounds simple so far but this solution has one big disadvantage related to teleport to house spell. Some players are using house teleports as emergency teleports. Blocking teleport randomly according to actions of other players on other game servers is not too good solution. Probably simpliest solution is to change teleport to house to teleport players outside portal they have house moved to instead of telporting to house itself (there are even running petitions for this change). Another solution is to teleport player to special cripled house - just one square with exit portal only (and message what game world he should to go to enter his house). This second solution has one advantage against the first one - teleport to house is used as emergency teleport because house is "safe" zone and if you die just after teleport you will lost no items. Not to mention that teleporting through house is actually curing poison (not sure if it is intended feature but it saved my life a few times).

creating (loading) instance of group of houses:
Not only accessing of instance but also creating (loading) it is different. Game server has instant access to information about land of owner trying to enter house. So if group is not loaded already, server is able to load and create players own land and according to information from group server it also knows right positions and actual size of outlands. But to create whole group instance server needs to retrieve data of all available outlands first from records of other members. This can take a while and loading of group of houses will be significatly slower then loading of single house. Are there any options how to speed up this?

yes. but it depends on technical backround of actual POH implementation. To speed up creating of instance it is probably possible to divide group of houses to "independent zones" the same way like map zones. Player, who is entering group of houses will enter his own house (each house in group still need at least one exit portal!) and server has all data to diplay it and can have also preloaded from group server basic positioning and parameters of outlands. So it is possible to create instance containing just land of actual owner entering house and reserved space for other lands and display this house to player with outlands blacked out. When data from other members records will be retrieved, server can build related zones according to retrieved information and then reveal them to client the same way like adjacent map zones are revealed when player come closer. I am not sure if it is possible to use zones with variable sizes (depending on size of land). This is one of reasons why i limited number of houses in group to 4. It is highest number of lands where it is possible to use zones of fixed size. It needs to apply some more restrictions on land positioning, however, so better it will be to use zones of variable size if possible..

build mode in group of houses:
Build mode should be a bit different. there is not single house but up to 4 lands and up to 4 players can make changes to their houses at time and they can be even on more levels. Fortunately, the decision to not allow working on outlands simplified this problem a lot. Each player can work only on his own land and the only time he is affected by other players can be situation when he is trying to expand border (ie, when player is adding new room over border of his house) and eventualy in case of building content on shared door hotspots. This means that player can work in build mode the same way like if it is single house except situation he wants to use door hotspot adjacent to land border or any feature on outlands. In such case client should check if his action is not in conflict with previous action of owner of related outland. I think that this can be speed up by "dirty" flags in record on group server. The decoration and furniture changes can be pushed to al lowners immediately, so there is probably no problem with synchronization.

Another problem is need of reloading house in case of room added or removed. I tried to invent some complex solution for this but it was too complicated to implement so i rather came with easy one. The simple solution is to allow such changes only in case there is just one player inside.