No, you can't easily use the same streaming URL if you stop and start a live event.
Each time you create and publish a new live output (and asset), a new streaming URL (GUID) will be used for the new locator.
That way, you're sure there won't be any cache conflict in the streaming endpoint and the content delivery network (CDN).
You can prepare (and know) the streaming URLs in advance because you can force a specific GUID for the streaming locator, and then decide the manifest name to use for the live output.
Let's say that you decide to use GUID 1a7ed69e-a361-433d-8a56-29c61872744f for the live output that you'll create tomorrow. When the day comes, you start the live event and create a live output. You can decide to use "conference1" for the manifest and force the GUID for the locator.
The streaming URL is predictable and is http://-.streaming.media.azure.net/1a7ed69e-a361-433d-8a56-29c61872744f/conference1.ism/manifest.
You can't reuse the same live output or asset multiple times. Think of the combination of the live output and asset as a tape recording.
After the live output has been recorded to the asset, you can't reuse it for another recording. There will be blob conflict or overwrites if you do that again.
Unless you plan to fully purge the blobs in the storage account, and purge the CDN completely, there will be problems.
There will likely still be problems because the fragments are already cached downstream at the CDN or in client device caches (for example, the browser cache).