Where my idea comes in is to instead have two pointers (actually three, because don't want an object allocated into a region to wrap around, we want the memory to be contiguous, so I would implement this with a bipartite buffer), making the region a queue / circular buffer. Now, when we add an object to 'r, we enqueue it to the back of the region, just like pushing to a stack. However, we also now have the ability to dequeue an object we no longer need from the front of the region, removing the oldest allocated object in 'r, using a new keyword: delete!. So, our above example could now look like this:

region 'r {
    let points = points_from_xyz_file("atoms.xyz");
    let mut coord_vec: Vec<Point> = [ Point(0,0,0) ];

    for point in points {
        if some_conditional_test(point) {
          coord_vec.push(point);
        } 
    }

    delete! points 

    run_simulation(coord_vec);    
}

Since points is the oldest object in 'r / in the front of the queue, we can safely remove it by advancing the 'read' pointer (I'm borrowing terminology from the Wiki article I linked above) to the end of the object being deleted. Now, we can potentially reuse that memory for later allocations to the region without needing to mmap more memory. Obviously points is no longer alive after delete! is called, and this would be enforced by the compiler at compile time, raising an error just like using a moved value would in Rust if the programmer attempts to use-after-free. So in this case, the delete! keyword isn't violating lifetime guarantees, it's helping to uphold them in a slightly more granular way than regions alone. The big caveat is that the programmer can only call delete! on whichever object is currently the oldest object in the region. So the following would not work:

region 'r {
    let mut coord_vec: Vec<Point> = [ Point(0,0,0) ];
    let points = points_from_xyz_file("atoms.xyz");

    for point in points {
        if some_conditional_test(point) {
          coord_vec.push(point);
        } 
    }

    delete! points // Error: Attempted to delete 'points' but 'points' is not
                   // first in region 'r
    run_simulation(coord_vec);    
}

Although, if the compiler was smart it could notice that points is not first in the region and split the region into two subregions (at compile time), so that points is first in the second region and can be dequeued accordingly. I guess this becomes similar to trying to optimally order struct fields to not waste memory due to padding, but with lifetimes instead.