Hi Kenny,
Thank you for your interest in this project, which is indeed of high priority for us.
The key challenge in getting the automated toString conversion to work is that unlike in previous versions of Java, the call to toString() is not longer (always) part of the bytecode. It happens automatically inside the JVM.
We therefore have to implement this fix entirely in the internal "guest JVM" that JPF implements.
Because of this, any proposal relating to this task greatly benefits from any (even small) proof of concept or demonstration that shows you can work with the internal JVM that JPF implements. This could be a patch that stops or prints a warning where the string conversion is needed. Even just more detailed information of what methods in JPF you would work on would demonstrate some insight into how JPF works for this. (You can find out more by running some failing tests and inspecting the executed code in JPF.)
The more concrete a proposal is, the higher its chances of getting accepted. A small pull request (PR) showing that you can successfully modify JPF in some way would be the clearest demonstration of this, and in the context of the difficulty of this task, it does not have to be complete or even fully functioning.
This advice applies to any GSoC project; for projects with complex execution platforms (such as JPF, RTEMS), evidence that you can successfully run the tests and make small modifications that also compile and run is what we are looking for. For entry-level projects, small proof-of-concept patches (PRs) show that you can successfully make useful modifications.