Model with variable number of "properties" of different types.
hstore is ideal for this job, and isn't in any way experimental; it's been a part of PostgreSQL since 8.3 and is way easier to use in 9.1 and above thanks to CREATE EXTENSION. 

The only real issue with hstore is that not all client drivers support converting hstore values to native maps or dictionaries, so you might need to get the properties for an entry as a table using the hstore sql function each, effectively converting the hstore to subtable result.

The only real alternatives I see are:


A simple master-detail table in EAV style. That'll work fine, it's just a bit annoying to query, you'll be using a lot of string_agg or array_agg calls and it's lots slower than hstore. This approach is completely portable across database systems.
Storing the properties as xml, which can be easier to parse from some applications and is sort-of indexable using functional indexes on xpath expressions. This approach is somewhat portable across database systems, in that it should work with any SQL/XML database.
Storing the properties as json, which is easy to consume from most applications but is currently non-indexable and pretty opaque to SQL at the moment (expect improvements in future Pg versions). This approach is somewhat PostgreSQL-specific, but you can use a text/memo/clob field to store json in any database.


As for re-using properties that're already defined, that'a a simple matter of maintaining a table of known property names. If you want you can generate it on the fly using SELECT DISTINCT skeys(properties) FROM thetable; queries on the properties hstores, but that'll be quite slow so I'd recommend maintaining a separate table.