Identity Reference between two bounded contexts

I am looking to get the best practice around DDD/CQRS principles for handing relationships between bounded contexts.

We have two BCs Property Management Context and Tenant Portal Context. We have the Home aggregate in the Tenant Portal context, which operates completely independent of the Property aggregate in the property management context. However, on creating a Home we are finding the need to store the PropertyId from the other BC in the initial event as a look-up.

I was initially of the opinion that event identity references across BCs were discouraged. However, someone in my team challenged that opinion and I'm struggling to find the resources that support either argument.

Is it considered acceptable to reference aggregate roots in other bounded contexts?

If it isn't recommended, would a better alternative be to purposefully obscure the relationship by trying to use context-specific language, such as LookUpCode or ExternalReferenceCode. Even though, there is a hidden implicit understanding that this is actually the PropertyId and unlikely be anything else for the near future.

Two different contrary suggestions I have seen to a similar question are:

• DDD - Association mapping between bounded contexts using Doctrine 2 - "The right way to reference an entity in another BC is by ID"
• DDD - aggregate root identity usage across bounded context bounderies - "If they each have a CustomerId then it defies the purpose of one context's concepts and language not leaking into other contexts."