There are no hard and fast rules for how to handle datasets with different projections, but here are some general comments on the separate database/schema question.
Separate databases are generally used for things that are very functionally different, where you are not likely to want to mix tables from one to the other in a query, for example, client data and static geographic data, would be good candidates to go into different databases. You don't want invoices in the same db as Brazilian trees. This is relevant because there is no built-in mechanism to do joins between tables in different DBs -- you need to use foreign data wrappers (or the older, dblink). Also, note that if you join two tables in separate DBs using foreign data wrappers, currently indexes will only be used for built-in Postgres types -- which means no spatial joins (as the spatial objects provided by Postgis are not a native type).
Separate schemas within the same database are used for a number of reasons.
- To separate things that are functionally different. You might want to put 3rd-party extension functions, such as PostGIS in their own schema (this can be useful with backups, see below). This means you are not backing up static data and functions along with dynamic data.
- To separate data for different users/clients. You can grant access for a user/role to specific schemas, so this can be used for security reason. You can also have a table with the same name but in a differently named schema.
When you use pg_dump to backup databases or move them to new servers, there is a switch (-n) to only include certain schemas. So, if you have static and dynamic data in separate schemas, or different client's data in different schemas, it makes it easy to run partial backups or just move some data to a new machine. This way you can also avoid backing up all the system functions, which will default to the public schema.
There is no reason to need to put British and Irish data, for example, in separate schemas or databases. As the SRID should always be explicitly set, there is really nothing to be gained from separating them. You should always set the SRID explicitly on table/column creation, eg,
CREATE TABLE some_table (geom geometry (GEOMETRY_TYPE, SRID));
or failing that use UpdateGeometrySRID to change the SRID. Both of these will update the meta data geometry_columns and prevent queries with functions that accidentally use different SRIDs by giving the well-known error:
ERROR: Operation on mixed SRID geometries
And, of course, if you wanted to do a query combining British and Irish grids on tables in the same database, you can always use ST_Transform on one of the geometries, but without the pain of having to use foreign data wrappers or dblink.
So to summarize, data you are likely to want to combine in queries should go in the same database. Separate 3rd party (extensions) from your own data. Use schemas according to backup strategies and possibly, to separate tables with the same name, but from different clients.