The issue of safe HTTP request methods and "safe" responses was discussed at length in the HTTP working group. It was noted that the request method is not the determiner of safety, but rather the server was the final arbiter. RFC 2310 ("The Safe Response Header Field") was proposed as one way that the origin server could note the safety of methods. The interesting observation was that most of the use cases only required knowledge of safety after the fact, and not a priori.

This wasn't supported in the use cases we looked at. Whether or not the GET method was "safe" was up to the server. Servers should, of course, be aware that there will be applications (web crawlers, cache warmers, etc.) that will pre-fetch GET data.

It may be that you mean something other than "safe", such as "freely callable without worry", whether or not the results actually are safe.

I don't find anything in the design of GET and HTTP that supports your conclusion, that the "get" method should be used when the "form is idempotent". In fact, it isn't a property of the form at all, it's a property of the processor of the form at the time the form is processed, to decide whether the form submission is or isn't idempotent. And there's no use case for having client software, search service crawlers or caching proxies automatically submit forms in advance, whether or not they are "idempotent".