If they have Sametime 9 then they should also have an SSC which sits on WAS. You should not install a Sametime 9 Community server without an SSC.
The SSC should be capable of handling SPNEGO although in only one other deployment the customer used a separate node as the SPNEGO enabled apps server.
But if we want to use SSO in Notes client (without saving username and password) then we are forced to use SPNEGO, and there are no alternatives, right?
Correct if you are using AD as the LDAP source for Sametime.
If the customer continued to use Domino then you could use "Domino single sign on" which means that the notes ID is passed to the Community server (or alternative Domino authentication server) and the ID is queried. If the user has access via their Notes ID then an LtpaToken is passed back to a mini web server running in the Sametime client. This LtpaToken is then passed to the Community server and that is used to sign in (without a password) to the Community server.
"Domino single sign on" only works if you are using the embedded Sametime client in Notes. If you use a standalone Connect client then you're only option is SPENGO.
"Domino single sign on" doesn't require an HTTP password to be present BUT other applications may need it if you use Domino as the LDAP source.
Customer does not have any SPNEGO-enabled WebSphere server to use for Authentication URL (and they do not want this one nor they have license for it)
Please explain what license they have. Even if they are using Sametime based on Domino licensing they are able to run an SSC and STProxy for iNotes (no mobile), This provides you with a licensed option to install WAS.
Notes clients need to be re-configured from Domino Token Based SSO to SPNEGO SSO (and I know from experience that it is a very problematic process to change login information in the notes client)
It can be a problem but if you have a good grasp of managed-settings.xml then it is possible. In my opinion, using managed-settings.xml works very well. Please do not try to use Domino desktop policies to control Eclipse settings, they are awful and rarely work as you expect.
I have not been faced with a change from one LDAP type to another. WAS should handle this OK as it's just a federated repository but the Community server will need to be reinstalled and possibly you may have issues with the SSC.
You'd be better creating a second environment using AD and then migrating users using managed-settings.xml and managed-community-configs.xml to handle the redirection of the client.
A well planned migration can work well. Yes there will be some problems but these will be client side and normally only small in number.