Once a risk has materialised, it is no longer a risk, it is an issue. As you know. At that point the risk no longer exists and should be closed.
Personally I raise the Issue, and reference the Risk number it is derived from. Then I close the risk and reference the issue it has become within the closing comments.
There can be no clear definition of when an issue is closed, it is a matter for local management. However, if the issue still exists and you have just issued a workaround, then the issue still exists and should not be closed. If by providing the "fix" you have actually closed the issue, i.e. the observed fault/defect/impact has been removed, but has created other issues that need to be fixed in due course, then close the original issue and raise one or more new ones to reflect the current fault/defect/impact.
Your question two is somewhat off-topic as opinion-based. I have seen many systems and implementations of methods, where the Risks and the Issues are represented in the same physical location with designations of Risk or Issue; and I have worked with many that keep them physically separated (for example in two separate tabs of a spreadsheet). Personally I believe:
- they are two different entities with some common attributes but many different ones
- they often have different audiences, or at least different management and mitigation processes
- they have fundamentally different impacts- Risks are, by their very nature, in the future whereas Issues are impacting the project now
Accordingly I will always want to manage them in two separate lists where I have a choice. Others may have other opinions and practises.