There is a couple of ways to do this. None is really good...
One way is to create a new set of templates that has the business rules in it. That is that the root page template only allows children of a specific type and any parsys used in the template(s) allow components from /apps/mysite/components/na/*. That one should not be in the "other" templates parsys allowedChildren.
If you know where the component is supposed to be on the page, you can have that one fixed and the page component could have a dropdown that makes is possible to add that component to the page in the correct place.
If we have the case that the component can be placed anywhere on the page ("why???!!!!"), added by anyone, but only once, and you should restrict it usage programatically... use a wrapper component and have that wrapper component in the "allowedParents" of your na-components. Then you also have to query the page's resources to see if it is the only instance. If not, do nothing.e the end component. Otherwise, the wrapper does nothing.
In my humble opinion, with about 2 years of CQ architecture behind me and 10 years of other CMS, trying to implement this kind of business rules in code sucks. This kinds of requirements have a strange ability to change and when the change comes, it is always very urgent to make the change. The more business rules you enforce into your code, the more development work it will require further along the lifeline of the system. To many implemented rules and you will find yourself doing nothing but adapting the system to the new business rules and no time to do the fun change request that business ordered a year ago. And then your system will be shut down.
Less rules in code make development work easier an gives the authors the ability to change how they want to use the system.
I would put your specific components in an group of its own, name in "Only use under /na" and tell the authors that "if you place it anywhere else, you have to buy the dev team a cake".
