Overall comments and concerns (note that some of it overlaps with my and/or
other peoples previous comments).

1) prefix_sendEntArrToParts and prefix_receiveEntArrToParts with blocking
receive may result into deadlock (unless send and receive are always in
send-then-receive order). Non-blocking send/receive will be required
along with prefix_finishSendReceiveEntArr (like MPI_Waitall), see below:

...setupSendReceive...() // to determine receives
...recieve...() // or ...send...()
...send...() // or ...receive...()
do_other_stuff() // for latency hiding
...finishSendReceive...() // like MPI_Waitall()

Also I agree set-up of communication upfront will be needed. Also part
handle(s) is/are not required, entity_set_handles should be entity_handles and
in receive I think 'target' should be 'source'. We should also describe what
exactly is expected in each command_code, i.e., MIGRATE/COPY. Moreover,
update of ghosts will require another call (for example, we may NOT want to
keep ghosts updated during mesh adaptivity that may request several local
migrations and/or parallel sub-divisions). It is likely to be a collective call
so we may want to add 'Par' in the end of function name as we do in
prefix_getNumOfTypePar. This will allow us to have non-collective version in
future (if any).

2) We should reserve fixed part IDs on each process/rank (as also mentioned
by Carl, i.e., 'n' bits for process/rank and 'm' bits for local part ID). In
same context, I think we should allow for other than 32bit signed int for
part IDs like iPartID_type (which can be typedefed to appropriate type, like
32bit signed int, during compile time by application).

3) We should revisit functions for any rank (i.e., off-process data), see below:

prefix_getNumPartIds, prefix_getNumPartIdsArr - do we need these? Instead if
we agree to 'm' bits for part IDs on each process/rank as above, we should
provide something like prefix_getMaxLocalPartId.

(prefix_getRank, prefix_getRankArr seems useful for partitioning service like
Zoltan and may be easily be supported by reserving bits for part IDs.
Similarly for prefix_getPartIdFromRank and prefix_getPartIdsFromRankArr).
We should distinguish function (in terms of names) that provide independent
remote information (nothing related to process on which it is called).

4) For neighboring parts, we may want to provide following functionalties
getOffProcessNbors/getNborsRanks, getOnProcessNbors and isPartNbor.

5) In general, we may want to mention expected complexity for functions (say,
O (log p), where p is number of processes/comm_size), may be each user and
developer can provide their estimate.

6) A comment will be useful to clarify that part ID is mainly used to
refer/identify remote parts. So part-handle are always local on-process ones.
(part ID is necessary in remote copy information, migration etc. and part
handle is require in serial iMesh functions etc.).

7) prefix_addEntToPart, prefix_rmvEntToPart, prefix_addEntArrToPart and
prefix_rmvEntArrToPart.  Possible to achieve this through send/receiveEntArr.
May be not be accomplished by entity-set functionality. Moreover, if we use
define it will be tedious across different compilers (due to underscores etc.).

8) It is not clear when only part-handle is sufficient and when only
partition-handle, and when both are needed. For example,
part handle seems sufficient for prefix_getPartIdFromPartHandle.

9) I do not know why we need entity_set_handle in getNumOfTypePar and
getNumOfTopoPar.

10) May want to distinguish functions (in terms of name) that take both
part-handle and entity-set-handle.

11) We can avoid MPI in function names. We can have ITAPS_Comm (which can be
typdefed to MPI_COMM for MPI and so on) leading to prefix_createPartition
(without MPI). Also in prefix_getPartitionCommMPI as prefix_getPartitionComm
(without MPI). At the same time, prefix_isPartitionCommMPI may be useful.

12) In general we may want to do some sort of sanity checks on function
arguments and names as we process. This is not to undermine others efforts.

13) We can look for abbreviation like Partition to Ptn and receive to recv
as Entity to Ent or remove to rmv or Array to Arr.

14) There are some minor typos (like getPartIdsFromPartHandle and
getPartHandlesFromPartId should be getPartIdFr... and getPartHandelFr... (no
's', respectively) and inconsistencies (in prefix_getParts should have
**part_handles) which we should try to clean up.