Regarding the proposal, thanks for putting it up, I have been mapping using something similar to the IndoorOSM proposal, but adjusting it where I needed to.
Some changes that I have been using:
Ignore the ground_level restriction. I tried doing this initially, but when mapping a building with 4 levels, each of which has entrances from outside (at that level), and for which the main entrance is on the top level, I could not see any benefit with this restriction.
Make the entrances/exits members of the relevant level relation, not the building relation. This includes the level information for the entrance/exit, whereas having it being a member of the building relation does not.
Currently for mapping the lifts/stairs I have been using a area (circular way), tagged with buildingpart:verticalpassage. To represent which levels this allows access to, it is included as a member of the associated level relation. Note that so far I have just been using this data for display purposes, and currently it is not expressive enough to say that, for example, there is a lift shaft here, but the lift does not stop on level 3. The role on the level relation could be possibly used in cases like this?
Some issues that I have encountered:
Could a way be used to represent an entrance to a building which has a width? This would be useful where you have two buildings that join, connected with a large (in width) corridor/space. Putting a node somewhere in the middle of the divide seems a bit broken.
Mapping an outdoor area on the roof of a building is a bit undefined. You could put the bits in the relevant level relation, but by also including the shell, you would be able to determine what bits are outdoors.
What is the intention behind shells for levels? I have not really found a use for them yet. If the building level has a hole in the middle, should the shell be no different, or should a multipolygon relation be used instead?