There are two types of multisite compatibility:
- Passive compatibility: doing nothing multisite specific, just works without breaking anything.
- Active compatibility: changing or extending multisite specific behavior.
I guess you are out for 1. See my slides from WordCamp Prague 2015 for the second part.
Plugins that do not say anything about multisite should not be activated as network plugins. WooCommerce for example creates some custom tables during the installation. If you activate it network-wide, the subsites don’t get these tables and the sky will fall onto your head.
Unfortunately, most plugins don’t check for their activation type, so they let you do the wrong activation.
related are UX problems like admin pointers or special "About" pages that you have to click away on ever subsite in non-compatible plugins. Yoast’s WP SEO is one example. This will be fixed in that plugin soon, I guess. :)
Other issues depend on what you do with that multisite. If you are building a multilingual website where each site is written in one language and the sites are connected with each other, you want to synchronize the posts when you write content. That means that you call
switch_to_blog() on the hook
save_post, and save the connected posts too.
save_post will be called multiple times during one request now. Many plugins are not aware of such a situation, so they just overwrite the post meta information for the connected posts, thinking that they are still on the first post.
Look out for plugins that are dealing with post meta and lack a check like this:
if ( is_multisite() && ms_is_switched() )
These plugins are not compatible.
Similar, albeit harder to specify, are issues when plugins touch user meta fields or rewrite rules.
Some plugins try write content into files without including the site ID in the file name. They are very likely broken too.
Like Tom said: Create a test installation, run every use case you can imagine. You cannot trust the plugin page, and usually there is not enough information anyway.