you'are absolutely right about the documentation, we are collecting feedback from our users and we are going to improve it also by adding some video tutorials. Until that, the intended way to use the documentation is to first have a look at the README that you will find in the Scripts folder and then to the one available in the Examples folder. We also provided an example for each kind of tracker you can use, that should help to provide a starting point that you can customize for your needs (every example is kept as simple as possible so it should be easily understandable). Finally the documentation that is available online is more related to the configuration of the tracker itself (there you will find the description of tracking parameters and the process involved in the creation of targets).
We will add pre-computed cache in the next update (later this week, or beginning of next one). This will, at least, make the default examples faster to load, but if you will modify tracking parameters you will need to re-generate the cache (this is the reason for not having provided the cache so far). Also, talking about Android we know about a bug that makes the loading of tracking data quite slow on some devices, we are also wokring on that and eventually this problem should be fixed with the next update too.
Talking about framerate, according to the test we did, we did not noticed a huge difference with other SDKs (frankly speaking, in some circumstances, " others' " perfomances were worst than ours...) nonetheless, it is undoubtly true that you may experience those issues you have described. Unfortunately, given the extremely high number of differences among Android devices (especially in terms of HW, cameras and OpenGLES implementations), it is not easy to find a solution that works for everybody but we keep doing our best to fix problems and improve performances especially when we are asked to. One quick note: we released an update few days ago that fixed several problems related to the camera on Android, may I ask you when you downloaded the plugin exactly?
The issue with squashed/stretched image is not normal at all. To my knowledge, in the past we had a bug related to that, but is was fixed, I will double check that it is really so.
The fact that the screen turns off is something that the developer can/should decide upon (using something like: Screen.sleepTimeout = SleepTimeout.NeverSleep;) what is wrong is the fact that when the app goes in background and then the user brings it back it should not re-start. Even though the plugin supports the latest version of Unity, it could be the case that something changed "under-the-hood" and it is preventing the plugin to work as expected. We will investigate this issue further and eventually fix the problem.
Regarding the tests with the Planar Tracker example, were you using the default target image? By the way, we really had no issues when we tried both the Object tracker and the Planar tracker using the computer's screen instead of printed images, unless you don't have very contrasted areas your monitor or unless you get so close to the screen that you see almost individual pixels, then you should not have problems. On the other hand, if you are using printed images, be absolutely sure that when you send the images to the printer, you did not choose to re-scale/fit the image to the sheet's size, many times it happens that the image get stretched a little and this can fool the tracker that will provide a wrong pose (hence a wrong green reference rectangle) - in other words double check that the aspect ratio is not modified. Also, when you scan just a portion of the target image, depending on the number of features that are found, you may get wrong results, to reduce this 'false' positives you could act on the configuration file).
Talking about all the available parameters that can be customized, specifically with reference to features descriptors and detectors, we decided to provide maximum flexibility to the experienced developer that can really customize the tracker using established computer vision techniques (no other SDK provides you the flexibility to experiment wiht all available descriptors/detectors, this is an advanced feature that requires some experience with Computer Vision and specifically with OpenCV). To this regards, the documentation one should have in mind is the one related to OpenCV itself. Nonetheless, it should not be strictly required to go deep to that level of detail - unless you want to - but, usually, what a developer should do is to modify a few numeric parameters like the number of features used for initialization and/or during tracking, the search resolution and so on...
That said, a review of the documentation is surely something we will do, we will try to also provide some 'pre-sets' for most common situations if this may help (especially for planar tracking scenarios). Meanwhile do not hesitate to ask for any doubt or information you may need.