The field profiling-project.id in ES is already a keyword (indexed string).
Should we accept a string in the agent as well instead of limiting it to an integer?
The required change in the collector is tiny, as projectID is already used as a string except for Metrics.ProjectID.

Accepting a string for a numeric value sounds like a overhead to me, that should be avoided. From a usability point of view, if the accepted string is not a numeric value, where and when does it let the user know about the expectation and what is the expected failing state and how can a user recover form this workflow? How the value is used internally in the backend should not matter to the user.

The benefit for the user would be to have a human understandable string that can be memorized easier. If you use 1, 2, 3... as the projectID, can you still remember what 34 stands for after a while? Instead you could have "obs-testing-metrics-cluster" or whatever you like.
Constraints and expectations need to be documented and checked at the agent and collector side.

How the value is used internally in the backend should not matter to the user.

To clarify, just meant to describe that the required changes are minimal.

this is just my personal opinion, but the use of project ID is an internal detail that users should not care about. for logical separation, there are tags (strings) that users can apply and are used to with every other concept of deployment.
Project ID is based on a concept, that is SaaS centric but doesn't fit well in the current integration anymore.