Hi,
1. I think that you want to change your checkout into a two steps checkout: first, the login view. Then, the cart/address view.
That way, you would have two different buttons that you could style separately as they would really be on different steps. Right now you're always on the same step. It's only the login and address views displaying or not based on the current status of the user (already connected as guest, or not yet connected as guest).
Now, even with your current checkout, it would be possible. You would have to do a view override of the show_block_login view file and add custom javascript code based on whether the user is connected as guest or not to add a different class to the button on page load.
2. The shipping method selection / calculations as well as taxes, coupons, etc are based on addresses. For the system of shipping methods to give back a list of shipping methods, you need to give him an address.
Before you click on the button to validate the address, the server doesn't know about the address.
While we could send the information already provided in the address before you click on the validation button and refresh the shipping methods, this causes a lot of problematics:
- If some of the fields are not filled then you have an incomplete address and shipping methods might depend on these not only the country. You might have configured shipping methods based on countries, but others might use shipping methods which need the zip code, the city, the state. If these are not provided, then the shipping plugins would get an address with missing information and some might break or not be able to return anything.
- To be able to calculate the shipping methods, the shipping address needs to be linked to the cart in the database. This requires also adding the address in the database. So we would have an address (potentially) half-filled in the database, that the user might actually not validate. But then the cart would be linked with an invalid address and a shipping method that might not be correct and should be "unlinked".
- In fact, in your case, the user is not even created yet in HikaShop and thus the address cannot even be linked to the user. So it brings other problems as the system wasn't designed to work with temporary, potentially not complete addresses to begin with.
The only solution I could see would require some complex code modifications as a custom work. (it's a lot easier as a custom work as in that case, you don't have to handle all the possible ways the HikaShop checkout could be configured and only focus on the situation on your website).