Yes, I would use a different table of locations. It would be no different than using another table for addresses or customers. Your Project table would hold the primary ProjectID (unique, meaningless, auto-enter, FM-Generated incrementing serial number) and your Countries table would hold its own primary CountryID serial plus the ProjectID. Each country/project combination would be a record in this Countries table.
As you've mentioned, reporting is one advantage of splitting the 1-to-many (1:n) into related tables but there are many other reasons, such as elimination of redundant data and allowing flexibility and growth. Repetitions should not normally be used for data. Whenever you see a situation where you begin putting 'like' fields within one table (or wanting repetitions), it usually indicates that another table is warranted.
UPDATE: I don't know your skill level so I will explain how to create a new country record the easy way: Once you connect Projects::ProjectID = Countries::ProjectID in your graph, check 'Allow creation of related' (in the connection dialog at the bottom) on the Countries side. Place a portal of Countries on your Project layout and put your country field(s) within the portal and add your countries directly there. Don't bother placing your Countries ProjectID within the portal - it would list the same number for every portal line AND it would always match the current project record's ID anyway. Also, if someone changed this Country Project ID, they would orphan that country record and it would disappear from the portal.
Could you not use a Value List, either referencing a Table with the list of countries in, or as non-Table based Value List?
The problem with a single field holding a multi-line of countries (which is what a value list would provide) is that one cannot produce a report where one Project can appear in two different sub-summary parts by Country.
Thanks. Didn't think of that - I've got drop downs and popups on my mind as I'm looking for inspiration to solve my Conditional Value List in a Portal problem... this came up on the search I did.